[cap-talk] Heresy: Confused Deputies do NOT Justify Capabilities

[Fred Spiessens]

Hi Jonathan, hi all,

Sorry for not following this discussion step by step. Here is a short  
list of observations about this topic that may be useful.

It is true that capabilities provide a "too good" solution to the  
confused deputy problem.
The confused deputy problem can be avoided in any protection system  
that provides all of the following :
1) unforgeable permissions (can only be acquired in a "legal" way)
2) that can be delegated explicitly (so that the using agent "knows"  
that he has it) for an explicit purpose (so that the using agent can  
understand the purpose of the delegation and act accordingly if he so  
chooses)
3) that can be applied explicitly (the using agent "controls" the use  
of the permission) for an explicit purpose (the using agent can rely  
on it that the protection system will not apply it for anything else)

For more details, see section 1.3.5 of my thesis (I recommend reading  
section 1.3 as a whole)
http://www.evoluware.eu/fsp_thesis.pdf

These requirements are sufficient, but not necessary. It is trivial to  
build a protection system  that avoids confused deputies: make all  
permissions available to everybody, then you don't have any deputies  
that can be confused.
However, the list of requirements above was devised for protection  
systems that support POLA.

Let us see for instance how object capabilities (good POLA supporters)  
implement these requirements:
1) object capabilities are unforgeable
2) they can be delegated explicitly (as arguments in messages) and  
they inextricably combine a permission  (access) with a purpose  
(sending messages to the designated object)
3) application for a purpose is explicit by sending messages to the  
object capability

The inextricable combination of permission and purpose is what is "too  
good" about capabilities in general, as it is only one specific way to  
ensure that requirements 2) and 3) are met. (a very elegant and  
effective way indeed!)
This observation is useful because it may provide some headroom in  
those hypothetical cases where the inextricable combination of  
permission and designation would be difficult to achieve or would have  
unwanted side effects. In such hypothetical cases we would have to  
ensure 2) and 3) in another way.

Stack-walking in an interesting ACL-based approach that can solve the  
problem within certain restrictions. It makes delegation explicit and  
relies on the deputy to reveal his purpose-for-using-a-permission to  
the protection system. It is analyzed in the thesis, section 8.1.2,   
"approach 1: check who's asking".   (I recommend reading section 8.1  
as a whole)

The challenge to make ACL's as good as capabilities - for supporting  
POLA and for avoiding Confused Deputies - still stands. Research into  
this field should be encouraged, as it will lead to more insight about  
the desirable properties of protection systems.

cheers,


Fred Spiessens

On 22 Aug 2008, at 18:03, Jonathan S. Shapiro wrote:

> In a note on coyotos-dev, Charlie Landau recently wrote:
>
>> That's not sufficient to avoid the confused deputy problem.
>
> This note is not a response to him. It's a response to the statement  
> per
> se: confused deputies do not justify capability-based systems.
>
> The underlying problem of a confused deputy is an API problem. The
> deputy acts at different moments with different authorities, and it
> needs to keep them separated. Capabilities provide ONE solution to  
> this,
> because they incorporate explicit designation of authority into every
> operation.
>
> But the reason they solve the problem is not because they are
> capabilities per se. The reason they solve the problem is that the API
> of a capability system uses explicit designation.
>
> An alternative design, involving explicit user identity or other
> authority-encapsulating objects, and having the ability to designate  
> the
> appropriate authority object with each operation, could solve the
> confused deputy problem equally well. It might not solve other  
> problems,
> but it would solve confused deputy.
>
>
>
> shap
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>