[cap-talk] Confused Deputies in Capability Systems
David-Sarah Hopwood
david.hopwood at industrial-designers.co.uk
Wed Feb 11 10:26:35 EST 2009
Toby Murray wrote:
[...]
> Of course, this example is purposefully simple. Suppose instead that the
> client exploited some buffer overflow or such in the service (which in
> my example I helpfully (ha!) illustrated the possibility of) so that it
> purposefully overwrote a variable that contained a c-list index with
> another small integer designating a second c-list integer. Then the
> service could end up incorrectly using the wrong capability -- again,
> inadvertently using a designation "given" to it by the client. I'd argue
> that this too is just as much a confused deputy as the above or Norm's
> prototypical Compiler example.
I disagree. "Confused deputy" does not mean just "any deputy process that
can be confused into doing the wrong thing"; it specifically refers to
a deputy that is vulnerable in the following situation:
a) the deputy is passed a designator by a client;
b) the client is not intended to have the authority to access the
designated object, and does not have permission to access it;
c) the deputy has, and is intended to have permission to use the
designated object (not necessarily for this client request);
d) there is some expectation as part of the system design that the
designator refers to the same object in the client and the deputy.
e) the normal way for the deputy to directly access the designated
object, checks only whether the deputy has some permission to access
it, not whether the client has permission.
For a c-list index, condition d) is not satisfied: c-lists are local
names, that should have no meaning when passed between processes. If
a client uses a local name as if it did have a shared meaning, then
that's a simple bug. If it uses the wrong name as a result of undefined
behaviour of the language in which it is written, that's a different
kind of bug (one that would be prevented by the kind of programming
language providing memory safety and strong encapsulation that is
normally advocated here).
> I chose to write an example akin to something one might be able to
> implement in a Capability-based Operating System like KeyKOS etc.
Yes, that's a limitation of the security properties that can be
provided by an operating system alone, when using languages in which
common bugs trigger behaviour that is undefined at the language level.
--
David-Sarah Hopwood ⚥
More information about the cap-talk
mailing list