Quoting Kenton Varda (2017-03-11 23:25:28) > I'm not totally convinced that this is a solvable problem (nor that it > is in any way unique to Cap'n Proto).
The trickiest problem that's occured to me is that capnproto's expressiveness gives you enough rope to hang yourself in ways that other rpc protocols don't. I could imagine not-so-carefully-designed APIs could have problems that allow for attacks where an attacker wires up remote objects talking to eachother and wasting eachother's time without any (or much) interaction from the attacker. This gets worse once you have more than two vats; you can end up with reflection attacks if you're not careful. Perhaps one could design APIs to pass in a resource quota or somesuch; one can think of access to cpu time/memory allocation/other resources as a form of ambient authority (and I think some systems that do cap security at the OS level have used this with their schedulers). This gets a bit weird though in that method calls and quota params would have to be correlated to the same vat. You could enforce this in the schema with existential types, but CapNProto doesn't have those, and you'd have to find a way of mapping them to your programming language, which in most cases would also not have them. And it still leaves completely open the question of how those APIs should even look. > But I suppose if a solution exists, it would be based around placing > limits on things like: > - Number of calls that can be in-flight at once. > - Total size of in-flight call parameters (we actually have code for > this already, which we use in Sandstorm to prevent an app from flooding > the system with calls). Tangent: haven't looked in great detail at the way sandstorm does things, but my instinct with something like this where one end of the connection is a "supervisor" running on the same OS, would be to use the OS's resource management as a first line of defense. i.e. put the bits that handle complicated calls in a cgroup with the grain, and only use "simple" calls to talk to the central server. This way it's basically fine if the per-grain supervisor get's DoS'd; it's going on the grain's tab. But obviously this isn't generally applicable. > In theory clients need to be able to handle disconnects anyway. In which case you could solve the deadlock problem with a timeout. -Ian -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/capnproto.
signature.asc
Description: signature
