[cap-talk] Confused Deputies in Capability Systems

[Matej Kosik]

Toby Murray wrote:
> On Thu, 2009-02-12 at 02:04 +0100, Matej Kosik wrote:
>> Toby Murray wrote:
>>> On Wed, 2009-02-11 at 14:43 +0100, Matej Kosik wrote:
>>>> 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), 
>>> Which you should -- It's been a little while since I've written C
>>> (Should have written the example in BitC instead ;)
>>>
>>>> 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) ?
>>> Yes.
>> I agree with you that the fragment of code above is buggy. I agree with
>> you that we can write buggy subsystems (that use capabilities). Was this
>> the point?
> 
> No. The bug was, like most of them, unintentional.

While my belief what errors can be unintenionally made, I am not as
skeptical as you that any sufficiently knowledgable person may write the
code you have shown.
*The code indicates deeper errors in thinking*. People with such errors
in thinking may exist, the question is, why should that matter?

I can imagine that someone emulates i386 processor in E (or Emily or
Pict) language and then instead of writing code E in he writes
instructions for that emulated processor. What implications does this
have for the E language? From my point of view, none.

> The point was to
> answer Bill's original question: "How can translating a name, such as
> clist item into a capability" result in a confused deputy, or something
> that resembles one.

I have seen only one example of confused deputy problem and this was
where the aim was to pretend security rather than to achieve it. I do
not distinguish between confused deputy and other flagrant errors (such
as randomly choosing a procedure visible from a given scope, randomly
generating some arguments and calling that function). That can be done
in any language but it has no implication on the usefulness of a given
language (even concerning security).

> 
> Cheers
> 
> Toby
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>