[cap-talk] Confused Deputy terminology (was: Re: Confused Deputies in Capability Systems)

[Jed Donnelley]

Regarding:

At 06:03 AM 2/7/2009, Toby Murray wrote:
http://www.eros-os.org/pipermail/cap-talk/2009-February/012165.html

>On Fri, 2009-02-06 at 22:08 +0000, Karp, Alan H wrote:
>>It's a bug if the service honors a request made with a forged 
>>authorization. It's a bug if the service uses its own rights 
>>incorrectly on behalf of a legitimate request, such as writing the 
>>wrong file.  Neither of these is a confused deputy.
>
>Why?
>
>I want a formal distinction, not a fuzzy one.

and:

At 06:06 AM 2/7/2009, Toby Murray wrote:
http://www.eros-os.org/pipermail/cap-talk/2009-February/012166.html

>I want to know whether there is anything that formally distinguishes 
>them from confused deputy vulnerabilities or whether this just a 
>fuzzy concept that has only subjective meaning.

I believe this:

"Not every program that misuses authority is a confused deputy. 
Sometimes misuse of authority is simply a result of a program error. 
The confused deputy problem occurs when the designation of an object 
is passed from one program to another, and the associated permission 
changes unintentionally, without any explicit action by either party. 
It is insidious because neither party did anything explicit to change 
the authority."

from http://en.wikipedia.org/wiki/Confused_deputy_problem

is the best I've found.  Is the above adequate for your need 
Toby?  If not then I think we should work on the Wikipedia wording.


With my interpretation of the above I haven't yet seen an example of 
a Confused Deputy in a capability system (the more general class 
including object/capability systems).  I agree with

At 01:01 PM 2/7/2009, David-Sarah Hopwood wrote:
http://www.eros-os.org/pipermail/cap-talk/2009-February/012168.html

>More generally, both cap-as-data and object-cap systems need to 
>validate capability *representations*, or ensure that invalid 
>representations cannot exist. If an invalid representation can exist 
>then it must not be usable, and that must not depend on an 
>application validating it or being able to validate it, or on 
>whether the application has access to the representation as data.

that there is an important distinction between a failure in the 
implementation of a capability system vs. a Confused Deputy 
vulnerability for applications using a capability system.  While it's 
certainly possible to have a vulnerability in a capability 
implementation (beyond those noted previously in this thread, I 
believe the "Reflection Problem" that I discussed in:

http://www.webstart.com/jed/papers/Managing-Domains/#s11

, long before the term "Confused Deputy" was coined, falls into this 
category), I'm not aware of any "Confused Deputy" vulnerabilities 
that meet the Wikipedia criteria in correctly implemented capability 
systems.  This is because, as noted elsewhere on this thread, the 
semantics of capability communication includes:

1.  Validity of the object reference (the capability) for access - 
the same access the sender had, and

2.  The ability to associate all parts of a message from a sender for 
the purposes of access control.

To me the above semantics obviate the possibility of a "Confused 
Deputy" vulnerability by the Wikipedia criteria.

I believe it is only when we get into specialized mechanisms like 
"rights amplification" (where a communicated capability can be used 
to achieve more access in the receiver than in the sender) that the 
possibility of "Confused Deputies" arises in capability 
systems.  Even in rights amplification situations I believe 
capability system implementations can make adequate information 
available to applications to avoid "Confused Deputy" vulnerabilities 
by the Wikipedia criteria.  Specifically, the "associated permission" 
can be made to only change (increase) with explicit action by the 
deputy.  If capability implementations don't make adequate 
information available, then I would again fault the 
implementation.  If they do make adequate information available, then 
any vulnerability isn't a "Confused Deputy".  I believe the 
possibility of confusing deputies into rights amplification is why 
we've had so many discussions focused on this topic - e.g. 
discussions about Horton where authority communication is still via 
capability but where rights amplification by responsible identity is 
still possible.

While this thread refers to various implementations, it seems to me 
(mostly?, entirely?) a discussion of terminology.

--Jed  http://www.webstart.com/jed-signature.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20090207/853b2ba9/attachment.html