[cap-talk] Loss of control (was: Re: A paper on web-keys)

[Jed Donnelley]

At 02:13 AM 2/3/2008, Toby Murray wrote:

>On Sat, 2008-02-02 at 23:44 -0800, Jed Donnelley wrote:
>
><lots of stuff on Confused Deputies and Horton>
>
> > As you likely recall, Horton tunnels can keep track
> > of the complete delegation path (identity to identity)
> > that a particular capability has followed.  The
> > particular policy that is used for access through
> > these tunnels can in principle be anything based
> > on the available information - including the full
> > delegation path (such flexibility worries me, and
> > now I see another reason why - below).
> >
> > What I just realized is that if the policy is based
> > only on the last delegatee (i.e. "who" last received
> > the capability), or in fact anything but the full
> > delegation chain, then it will be subject to the
> > Confused Deputy problem.
>
><because the last delegatee may end up using some of their ambient
>authority (based on their Who) when exercising a delegated capability>

Exactly.

> > However, I believe that if the policy in the Horton
> > tunnel grants access based on access that would
> > only be available to all the delegatees along the
> > delegation chain, then the Confused Deputy problem
> > can't arise.
>
>In other words, the delegatee can access the resource designated by the
>delegated cap if and only if (iff) all of those in the chain can do so.

Exactly.

>This enforces the property that the deputy can access the resource iff
>its client can. This is precisely what is required to prevent Confused
>Deputy vulnerabilities, because it ensures that the deputy does not
>wield authority in excess of that possessed by its client and, hence, is
>not inappropriately using its own (private) authority on behalf of its
>client.

I agree.  I believe I understood this abstractly, but
I hadn't previously fully understood the consequences
for access control policy in Horton tunnels.  Perhaps
MarkM understood this better than I, but I'm glad to
better understand it now.

>(See Section 6.1 of
>web.comlab.ox.ac.uk/oucl/work/toby.murray/papers/AALPE.pdf
>in which this point was made.)

Hmmm.  I believe this is the Section 6.1 that you refer to:
_________
6.1 Analysing Authority in Capability Systems

In the Confused Deputy example, it is interesting to consider how Alice might
be prevented from having authority to overwrite Bill. One solution might be
for Carol to check the filename she is passed when invoked and to not write to
this file if it is Bill. However this raises the question: what if 
the subject that
executes Carol has permission to write to Bill? Should Carol then write to Bill
on that subject's behalf? Unfortunately, as noted by Spiessens [28], Carol does
not have the information available to make this determination. Even if she can
examine the access control list for Bill, it's possible that Alice is 
executing her
on behalf of some other subject who does have the relevant permission.
When the Confused Deputy was first described [6], it was noted that this
problem largely disappears when considered within the context of an access
control system that unifies designation and permission, such as those based on
capabilities [4]. If Alice can designate Bill to Carol if and only if 
she herself has
permission to Bill, then Carol will write to Bill if and only if 
Alice has permission
to write to Bill, since Carol uses Alice's designation when attempting to write
the output. Hence, another possible remedy would be to abandon the use of
identity-based access controls, such as the access control lists 
modelled in the
example, in favour of a capability-based approach.

Capability systems are interesting not only because they elegantly solve the
Confused Deputy problem. They also naturally support the construction 
of systems
that adhere to the principle of least authority. Further, many of the common
abstractions used in capability systems are designed to provide one object
with authority to access another, but not direct permission. Hence, being able
to reason about authority is crucial for an understanding of many of 
these abstractions.
For these reasons, capability systems present an attractive target for
the application of our techniques.
____________________

I don't recognize the above "all in the chain" limit on
access control in the above paragraphs.  I tried to follow
back through your paper to see if it tied in there, but still
didn't find it.  Please clarify further if you'd like my
further review to see if I can find it there.

In any case, I don't mind reinventing the wheel, as long
as I've got the right idea.

Regarding:

At 01:57 AM 2/3/2008, Toby Murray wrote:
>...
>Confused Deputy vulnerabilities are possible whenever capability
>possession is not sufficient for access.

Hmmm.  I don't think I'm following you above.  Perhaps the
Horton delegation example is confusing me.

In the case with the Horton tunnels, there is nothing
else besides the capability that can contribute to
what is needed for access - unless one considers
the state in the PDP (e.g. a change in the condition
of an identity - somebody was kicked off the board)
as something besides the capability.

However, it is always the case that state besides
the capability can result in failure of a request.
Just consider two subjects that both have read/write
access to a file.  One destroys the file and then
the other tries to read it - boom, no access even
though the capability hasn't changed.

What is happening in the Horton tunnels is that
as a capability is delegated from one subject to
another, it is changed.  The capability that was
sent from Alice is not the same capability that
is received by Bob.  In particular the capability
that is received by Bob has been 're labeled'
(annotated) as having been delegated from Alice
to Bob.  This different label can interact with
Horton's internal state (e.g. information about
the "who" identities) so as to change what
access is available.

The question then arises as to whether this
re annotation may grant Bob more access through
the capability he received than the access that
Alice had to begin with.  As long as Bob doesn't
receive any access that Alice didn't have through
the capability Bob received, then no Confused
Deputy.

>In these cases,

Namely, when "capability possession is not sufficient for access."?
I assume.

>ambient
>authority necessarily exists and thus opens up the possibility of
>confused deputies.

Sorry, but I don't understand the above.  As I noted above, I
believe capability possession is never (almost never anyway)
sufficient for access.  To decide whether to grant access,
the serving object must consider both the capability and
it's internal state - which can change at any time
in response to external conditions.

>The deputy cannot know whose authority it is using on
>behalf of its client if there is the possibility that the deputy is
>using ambient authority to access whatever resource the client has
>designated.

I think the Horton case is made more complex by the fact
that the capability Alice sends isn't the one that Bob
receives.  If what Bob received was exactly the capability
that Alice sent, then I believe there would be no Deputy
Confusion possible.  Carol (the server of the capability)
would have no way to distinguish an access by Alice from
one by Bob.

In the case of the Horton tunnel, Horton (though not
Carol) *can* tell the difference between the capabilities
wielded by Alice and Bob, because Horton is controlling
the labeling of each.  Horton's state regarding the
Alice who or the Bob who can change at any time, whether
or not one considers it "ambient".

>In a hybrid system,

Gosh, I'm sorry, but I'm afraid I'm not sure just
what a "hybrid" system is.  Is Horton a "hybrid"
system?  I never thought of it in that light.  I
consider Horton a pure object capability system.
However, as noted in my previous message:

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

if the access control policy in the Horton tunnels
doesn't have the "least access of any identity on
the delegation chain" property, then Horton can
give rise to Confused Deputies.

>the deputy is necessarily using ambient authority

Is state in the object server "ambient authority"?
That isn't how I usually think of ambient authority.
The only authority available in the invocation is
that of the capability, but it has to be combined
with the state of the object server to determine
access.

>when it exercises the cap passed to it by its client and is thus totally
>confusable.

Since I don't really know what you mean by a "hybrid system",
I'm afraid I can't comment intelligently on the above.

Sorry this response started out so seemingly well
("Exactly.  Exactly") and has ended in such an apparent
muddle.  I believe (though I admit I'm not so confident
now) that I understand what is going on, but I can't
make it out in your words above.

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