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

[Toby Murray]

On Sun, 2008-02-03 at 04:09 -0800, Jed Donnelley wrote:
> At 02:13 AM 2/3/2008, Toby Murray wrote:
> >(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
> 

Yes.

I was referring in particular to this part:

> 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.

Which coincides with what I said earlier in this thread:
 
> >This [granting the delegatee the intersection of the permissions of 
> >all preceding subjects in the delegation chain] 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 didn't mean to imply that this section previously raised your idea
about giving the delegatee the intersection of the permissions of
previous delegatees. But your idea here is an instance of enforcing that
the deputy (e.g. final delegatee in the Horton exmaple) can access a
resource if and only if its client (e.g. the previous delegatee) can and
that this more general idea is what I tried to express in Section 6.1.

> I don't recognize the above "all in the chain" limit on
> access control in the above paragraphs.

That's because it isn't there. The sentences I quoted above state a more
general property that I believe the "all in the chain" idea is an
example of.

> 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

This is precisely what I'm talking about. if the PDP state is used to
decide access requests (as MarkM has said) then this state contributes
to a subject's authority -- thereby giving the subject ambient
authority.

As soon as a deputy has ambient authority, it is confusable since it
can't be sure that it isn't incorrectly exercising its ambient authority
on behalf of its clients.


> 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.

Depending on the internal state, this grants the holder of the cap
different authority. Say for example the internal state is "Users on the
Board can use this capability, but others cannot.". Then when delegated
to someone whose Who identity is on the Board, then the capability
becomes useful, but in the hands of someone whose Who is not on the
board it is useless. 

If a non-Board member delegates it to a Board member and the Board
member uses it on behalf of the delegator, then the Board member may be
using its Bord-member authority incorrectly on behalf of its client (the
delegator). Hence, the Board member is confusable because the PDP state
is being used to decide whether this capability can be exercised.

> 
> 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.

Right. But one could have PDP state that does allow Bob to gain access
that Alice doesn't have -- e.g. the Board member example above.

Hence, as MarkM says, the use of PDP to decide whether caps can be
exercised creates ambient authority and thereby opens up the possibility
of confused deputy vulnerabilities.

> 
> >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.

Yes but the server's internal state is independent of the particular
client that is invoking it. The Horton PDP state is not, since it can
depend on the Who of the subject invoking the capability. Hence, the
server's internal state cannot give the subject ambient authority, while
the Horton PDP can. This is MarkM's point.

Cheers

Toby