[cap-talk] Confused Deputies in Capability Systems

[David-Sarah Hopwood]

Toby Murray wrote:
> On Wed, 2009-02-11 at 15:26 +0000, David-Sarah Hopwood wrote:
>>  "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.
> 
> I like that we're working with a concrete definition. Cheers for
> providing it.

It may need some refinement, but it's a start.

>> For a c-list index, condition d) is not satisfied: c-lists are local
>> names, that should have no meaning when passed between processes.
> 
> I disagree. When a client sends a message containing an integer that it
> knows will be interpreted as a c-list index in the server's namespace,
> then in sending integer N the client is clearly referring to "clist slot
> N of the server process that will interpret N as a c-list index".

It is *always* a design error to send c-list indices between processes.
They're an implementation detail, and depending on them across processes
is a violation of some process' encapsulation. (The same applies to
variable names.)

>> If a client uses a local name as if it did have a shared meaning, then
>> that's a simple bug.
> 
> Where is the line drawn? We've often considered XSRF bugs as confused
> deputies. Here a "local" (e.g. intranet URL) name is being guessed by a
> client.

XSRF as a class of attacks depends on the fact that URLs in general are
potentially global names. There is no way to assert that an URL is a local
name in a particular scope when using it; firewalls are an ad hoc attempt
to infer scope from network location, which is clearly not reliable.

-- 
David-Sarah Hopwood ⚥