[cap-talk] Confused Deputies in Capability Systems

Toby Murray toby.murray at comlab.ox.ac.uk
Fri Feb 6 10:12:01 EST 2009


On Fri, 2009-02-06 at 10:49 -0500, Sandro Magi wrote:
> An object-capability program that uses no rights amplification is not
> subject to confused deputies.

That's a strong claim. Along with the claim that rights amplification
can lead to confused deputies, it equates the possibility of confused
deputies with rights amplification. I'm not sure it's correct -- I think
we could construct a confused deputy without rights amplification (of
any kind). 

Here's another strong claim that could be just as incorrect: any
exploitable failure to vet a capability can result in a confused deputy
and vice-versa. This equates confused deputies with
failure-to-validate-inputs rather than increased authority of the
service like your claim does. I'm not sure which is correct because I
think of confused deputies in both senses.

A first attempt to build a confused deputy that does not use rights
amplification:

Consider the final example from
http://www.comlab.ox.ac.uk/people/toby.murray/papers/NDA.pdf in which
users use non-delegatable authority provided by a "credential"
capability to access classified networks via routers who are supposed to
check the authenticity of such credentials before relying on them.
Suppose a router fails to authenticate a credential. Then in a very
strict sense, it could be considered a confused deputy.

The router has the authority to grant access to classified networks for
the purpose of doing so only to individuals with appropriate security
clearance. It is being "confused" into using this authority for another
purpose, namely granting access to any invidivuals. 

What distinguishes it from a classic confused deputy? In other words,
what is the difference between confused deputy and
failure-to-perform-input-validation?

Cheers

Toby


More information about the cap-talk mailing list