[cap-talk] Confused Deputies in Capability Systems

[Matej Kosik]

Toby Murray wrote:
> On Tue, 2009-02-10 at 21:31 -0800, Bill Frantz wrote:
>> marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) on Tuesday, February 10, 2009 wrote:
>>
>>> It's even simpler.  A confused deputy can also arise in capability systems
>>> if a capability is designated by a symbolic name rather than a capability.
>>> Any service that translates names to capabilities can potentially have a
>>> confused deputy problem.
>> I am truly confused. How does translating a name, such as clist item[5],
>> into a capability introduce the problem of using the wrong subject to check
>> the authority, which is the essence of confused deputy?
> 
> Suppose one process has a really powerful capability in clist slot N.
> Suppose it is implemented like this:
> 
> char msg[] = ... 
> char rmsg[] = ...
> unsigned int len;
> while (true) {
>     uint index, replyCap;
>     recvFromAnyone(msg,sizeof(msg),&len,&replyCap);
>     index = atoi(msg);
>     sendAndReceive(index,msg
> +sizeof(uint),len-sizeof(uint),rmsg,sizeof(rmsg),&len);
>     sendMessage(replyCap,rmsg,len)
> }

If I ignore the (probable) misuse of `sizeof' operator for determining
the size of the message (as opposed to the size of the pointer to the
message), I would like to ask:

Is the first parameter of `sendAndReceive' function interpreted (by
kernel) as capability? (i.e. an index to a c-list of the process that
executes this code) ?

> 
> It waits to be invoked with a message containing an unsigned integer
> index and then some arbitrary message contents. It then invoked the
> capability designated by the unsigned int in the message, passing as the
> message the rest of the message contents before passing the reply back
> to the original invoker.
> 
> This process is the ultimate confused deputy, no?
> 
> Cheers
> 
> Toby
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>