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

[David Hopwood]

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.

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

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.

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

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. Also note that my point was much more
general than the case where system B only adds ACL checks.

-- 
David Hopwood