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

[Jed Donnelley]

At 04:36 PM 2/2/2008, David Hopwood wrote:
>Jed Donnelley wrote:
> > At 07:53 PM 2/1/2008, David Hopwood wrote:
> >> Bill Frantz wrote:
> >>> erights at gmail.com (Mark Miller) on Friday, February 1, 2008 wrote:
> >>>
> >>>> On Feb 1, 2008 8:46 AM, Karp, Alan H <alan.karp at hp.com> wrote:
> >>>>> [...]  Actually, I was thinking along the lines of an
> >>>>> additional, non-ocap check.  (You know how much I like to cross
> >>>>> levels of abstraction.)  For example, "This capability can 
> only be used
> >>>>> by clients in my domain."  How that might be implemented is left as an
> >>>>> exercise for the reader.
> >>>>
> >>>> I'm not concerned with how it's implemented. I'm concerned that by
> >>>> adding this ACL check, you now have a classic "hybrid capability
> >>>> systems". To the degree that you depend on this ACL check for access
> >>>> control, you have all the classic ACL problems, including confused
> >>>> deputy. As I've said before, it might be a good strategy in some
> >>>> contexts to create such mixed systems as a legacy bridge. But Waterken
> >>>> does not yet have an ACL legacy we need to bridge.
> >>>
> >>> I don't see how it is vulnerable to confused deputy.  The check that
> >>> Alan was suggesting is only an additional reason to deny a request.
> >>> You still need the capability (web key) to access a resource, so the
> >>> capability model protections are still in force.
> >>
> >> I don't agree with this argument. If system A has a given set of security
> >> mechanisms, and system B has the same mechanisms plus additional ones
> >> that only act to deny some requests, then it is not valid to conclude that
> >> B is automatically no less secure than A. The reason is that the 
> effects on
> >> user behaviour must be taken into account: if users or administrators rely
> >> on the existence of the extra checks, but those checks are flawed in any
> >> way, then they will end up with weaker security than if they had been
> >> required to express a comparable policy using only the mechanisms of A.
> >
> > I agree with what you say above in the general case.
> > However, in this case Bill is referring specifically
> > to the confused deputy problem.  Since all permissions
> > are explicitly delegated as parameters (no separation
> > of designation and authority), the confused deputy
> > situation can't happen - even if sometimes, perversely,
> > the communicated "permission" (reference) yields no
> > actual authority.

I was (sadly) wrong about the above - see below.  However, I
still don't believe you are correct about this:

>Whatever security properties you rely on the ACL checks to enforce, are
>vulnerable to confused deputy attacks.

I think the above may and may not be true, depending on how
the enforcement is done - see below.

>The example given was "This capability can only be used by clients in my
>domain." So "being in a given domain" (however "domains" are defined) is
>an ambient authority. If the domain restriction prevents any attacks, then
>confused deputies in the domain become possible vectors for those attacks.

In that case I think I agree - see more below.

>If it doesn't prevent any attack, OTOH, then why are we complicating the
>system, and requiring users to bypass security in cases where they believe
>that cross-domain delegation is legitimate? (Attempting to persuade people
>who believe they need the extra checks to use the system is not a good
>reason, since the disadvantages of having redundant security mechanisms
>far outweigh any such advantage.)

I don't see why this is necessarily so, though it could be the case.

>Sandro Magi wrote:
> > Unless users and/or developers start relying purely on the ACL and not
> > capabilities to control access, which I believe is David's point.
>
>No, it's not necessary that users or developers rely *purely* on the ACL.
>Anything that they rely on it for is potentially vulnerable to the attacks
>that ACLs are usually vulnerable to.

Potentially yes, but not necessarily - please read on, here comes
the meat of the matter from my perspective:

>... my point was much more
>general than the case where system B only adds ACL checks.

Your point was:

>If system A has a given set of security
>mechanisms, and system B has the same mechanisms plus additional ones
>that only act to deny some requests, then it is not valid to conclude that
>B is automatically no less secure than A. The reason is that the effects on
>user behaviour must be taken into account: if users or administrators rely
>on the existence of the extra checks, but those checks are flawed in any
>way, then they will end up with weaker security than if they had been
>required to express a comparable policy using only the mechanisms of A.

As I noted, I agree with this point.  We know of examples where
such a system B simply has some additional mechanisms to deny
more requests than a system A, but where system B is less secure
as you say above.  As you say, this can at least happen because
of changed user behavior (e.g. sharing passwords) if for no other
reason.  I give an example below where a Horton policy that adds
only additional access blocks can indeed cause Confused Deputies.

However, to reason from the above that if a system like
Web-keys adds a specific mechanism that only denies some
requests then the expanded Web-keys mechanism must
inherit all the security problems of ACLs, such as the
Confused Deputy, is flawed logic.

Such an expanded Web-keys system may end up with some
of the problems of ACLs (seems to if I follow what you
say above), but it won't necessarily (even if we accept
the above statement as I do) pick up any or all of them.

In particular, the Confused Deputy problem is a very
specific problem.  It only occurs when a program with
some privileges (the deputy) acts on a request from a
program with other privileges (the requester), and the
deputy is confused into acting with it's own privileges
on behalf of the requester because it can't tell which
privileges the requester had.

Hmmm.  I just realized something.  I wonder if this
might be what you are getting at.  Let me illustrate
by discussing a couple of possible PDP policies that
might be used in some Horton(-like) tunnels <pardon
my shift of emphasis, but it's my interest and I
think the reasoning might be applicable>.  One of these
policy approaches results in Confused Deputies and the
other I believe does not.

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.  If the last delegation
of a capability was from, say, somebody not on
the executive board to somebody who is on the
executive board, and the policy inside the Horton
tunnel then grants additional access to the
recipient of that last delegation based on
board membership, then a Confused Deputy situation
will arise.

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.  This is a rather tight restriction
that I wasn't previously unaware of.  It is interesting
to me that there is such a strong constraint on the
sort of policy that can be in such a Horton tunnel
and still avoid the Confused Deputy problem.

I don't know if the above reasoning will shed any
light on whether or not the additional access
blocks in Web-keys might or might not result in
the Confused Deputy problem there, but I am glad
to have thought about this enough to I realize how
tightly constrained policies must be for such
Horton tunnels to avoid Confused Deputies.

Thanks for pursuing the discussion.  Please let me
know if it seems I'm still missing something.

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