[cap-talk] Confused deputies in hybrid systems (weekend activity apology)

[Jed Donnelley]

On 2/4/2008 11:04 AM, Jonathan S. Shapiro wrote:
> On Mon, 2008-02-04 at 08:19 +0000, Toby Murray wrote:
>> Suppose I'm in the domain and, hence, can use the capability. I delegate
>> it to Bob who isn't in the domain -- he can't use it since he's not in
>> the domain.
>>
>> Bob delegates it to some service that IS in the domain. The service may
>> incorrectly use this capability on Bob's behalf, since the capability is
>> more powerful in the hands of the service than it is in Bob's. 
>>
>> This service is potentially confusable.
> 
> All:
> 
> This discussion seems greatly confused. That is: it seems self-evident
> that it cannot possibly be correct.
> 
> You all apparently agree that a pure capability system is not subject to
> the confused deputy.

The above statement seems a bit odd to me when I just
gave an example of a confused deputy in a pure capability
system (Horton with confusion inducing PDP):

http://www.eros-os.org/pipermail/cap-talk/2008-February/009728.html
(which points to:
http://www.eros-os.org/pipermail/cap-talk/2008-February/009721.html
).

Sorry for all the activity over the weekend.  I realize it
may be a bit difficult to catch up with these threads.

> This is of course false. The use of capabilities as
> an underlying permissions substrate does not preclude the presence of
> buggy programs.

A confused deputy is at least a very special case of a
"buggy" program - even if one tries to fit it into that
category.  The deputy in the "confused" case doesn't
have enough information to know how to proceed, bug
or no bug.  Perhaps you could call this a "buggy"
architecture, but don't blame the deputy (the program).

> Provided that it requires capabilities to be designated (i.e. the
> capability portion is not an ambient capability system), a hybrid system
> (i.e. one intersectiong capabilities and ACLs) is precisely as
> unconfused as the system lacking the intersection restrictions. It is,
> in fact, strictly less powerful than the pure system.

As David Hopwood pointed out, being strictly less powerful
doesn't necessarily make it any less likely to result in
confused deputies.

> In consequence, it
> has precisely the same degree of inherent confusion as the pure
> capability system.

I'm not sure I understand what you are saying above Jonathan,
but if I do then I disagree.  I believe I also showed an
example (with Horton, but I believe any "behind the scenes"
state manipulation mechanism will have the same properties)
where removing some access in a system that is free of
confused deputy situations (remember, it's the information
that the deputy has available, not something "buggy" about
the operation of the deputy) can result in a system
that has confused deputies.

> The danger in a hybrid system does not lie in the intersection of a
> second, orthogonal permissions system. It lies in the laziness of
> programmers, who may come to pass capabilities promiscuously in the
> mistaken belief that the ACL system is sufficient.
> 
>> In any case in which a service may get more authority than its client
>> from a capability passed to it by its client, the service is potentially
>> confusable.
> 
> Your statement confuses permission with authority. The service did not
> get more authority than its client held. The client had sufficient
> authority to pass the capability into the service domain. In
> consequence, any authority granted thereby to the service already fell
> within the client's authority BY DEFINITION.

Hmmm.  The above statement is very interesting.  In the above
statement you (Jonathan) seem to be switching the definition of
the "capability" term to something more like what I used in my
Managing Domains paper - namely, whatever authority is available
through an "invoke" interface as opposed to focusing on the
token itself.

I believe that common usage on this list is that a "capability"
refers to the token that is communicated in the implementation.

By that definition I agree with what Toby said.  Any "behind the
scenes" state can result in the object/process/domain receiving
a capability getting more authority from it than the sending
object/process/domain had.

The example I gave recently (noted above) was an inappropriate
Horton implementation where access is based only on the last
link of a delegation (more like ACLs).  That is an example
of a case where the receiver of the "capability" (the
token) gets more authority than the sender had.  I
believe Toby is exactly right that it is this situation
that results in the confused deputy scenario.

I also recently described how any "rights amplification"
situation can give rise to confused deputies:

http://www.eros-os.org/pipermail/cap-talk/2008-February/009745.html

so I agree with your criticism of such mechanisms.

--Jed  http://www.webstart.com/jed/