[cap-talk] Confused deputies in hybrid systems (was: Loss of control)

[Jed Donnelley]

At 01:09 AM 2/5/2008, Toby Murray wrote:
>On Mon, 2008-02-04 at 14:04 -0500, Jonathan S. Shapiro wrote:
> > You all apparently agree that a pure capability system is not subject to
> > the confused deputy.
>
>No. I think this is a long-held belief that this current discussion has
>disproved.

I share the above view.  Having examples has certainly
made the sorts of confused deputies possible over pure
capability systems clearer to me.

> > 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.
>
>Can you provide any evidence (or, even better) a proof to support this
>claim?

I don't understand the above enough to comment.

> > On Mon, 2008-02-04 at 08:19 +0000, Toby Murray wrote:
> > > 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 feel
> > within the client's authority BY DEFINITION.
>
>I see what you're trying to say but I disagree.

Whew.  I wish you could explain it to me Toby.

>Note that these are
>different KINDS of authority. When in the hands of the client, the
>authority is "authority to cause the service to perform X on my behalf",
>when in the service's hands its "authority to perform X directly".

I really don't get what you are meaning with these different
sorts of authority.  In the pure capability form, all that
is available to either client or server is the opportunity
to invoke the capability in question.

If there is something in the environment that can make
such invocations yield more authority from the server
than they can in the client, the confused deputies
are possible.

Here are two examples:

1.  Rights amplification - if the server just happens to
have some other capability which, if communicated along with
that passed in from the client, will result in more authority
(the ability to do something that the client was unable to
do), then the serve can become a confused deputy.

2.  "Behind the scenes state" mechanisms like Horton where
the capability that the client sent differs from that which
the server receives.  With Horton the client sends a capability
into the Horton tunnel labeled with one responsibility (last
delegate), and when it is received by the server it is labeled
with a different delegation chain.  This can result in different
authority for the server - depending possibly on something
like a Horton policy implementation or possibly other "behind
the scenes" state manipulation.

In both these cases it seems to me we have a real increase
in the authority of the server as a result of receiving the
capability that is greater than just the authority that
the client had.

To me this isn't 'just' a matter of one's "notion" of
authority, but is a practical situation.  I still can't
figure out if we are just talking cross purposes because
of word usage or if there is a difference of substance.

>Now depending on your notion of authority, one may argue that the
>authority to do something directly vs. the authority to cause another to
>do it for you, that the former is always strictly GREATER than the
>latter because one need not rely on anyone else to exercise it.

Ah ...  Maybe I'm finally getting what you guys are talking about.

Let me put it into my own words and see if I'm getting it.

What I guess you are saying is that by virtue of having the
potential to confuse the deputy, the client actually does
have the full authority that the server has.  It has it
by virtue of the possibility of getting the server to
act on behalf of the client who is exploiting the confusion.
Is that the basic idea?

However, even if this is the case I disagree.  It may be,
for example, that the code of the server is such that the
client can only get the server to exercise some of the
server's increased authority on behalf of the client.
Certainly a limiting case is where the client can't
get the server to exercise any of it's increased
authority on the client's behalf.  The server may
respond to all client requests with, "Thank you very
much." and just exploit any communicated capabilities
as desired.  In that case there is no exploitable
confused deputy, but the confused deputy environment
exists, because the deputy (server) doesn't know what
authority was really communicated from the client.
The server may think that what was communicated was
exactly that which is available via invocations on
the received capability, but as we have seen above
this may result in more authority than the client
had.

>Hence, I stand by my claim that the problem is that the cap is more
>poweful in the hands of the sevice than the client (i.e. grants the
>service more authority than it does the client).

I still agree with the above (as per above), but
since there are still parts of this discussion that
I'm not following, I hope the above helps clarify
any differences in our views.

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