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

[Jed Donnelley]

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.

Just checking myself Bill.  I hope you don't mind my
stepping in.

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