[cap-talk] Confused Deputies in Capability Systems

Toby Murray toby.murray at comlab.ox.ac.uk
Fri Feb 6 11:03:13 EST 2009

On Fri, 2009-02-06 at 11:34 -0500, Sandro Magi wrote:
> Toby Murray wrote:
> > 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.
> I don't see how that could work. The access check is performed before
> sending a capability to a service, in which case the service can rely on
> the parameter being authorized, unless it explicitly amplifies the
> rights derived from the given capability. Capabilities implicitly carry
> an authorization context with them which ACL invocations do not.

Capabilities do carry an implicit authorisation, the question is,
however, from whom (is that authorisation).

> > 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.
> Isn't the router amplifying a credential to a stream to access the
> protected network?

No it's handing out IP addresses and manipulating internal firewall

>  I would consider that a rights amplification.

It isn't, at least not the way we usually think about it.

> Analogously, the Waterken server amplifies a URL to an actual object
> reference when it serves a request on that object, so it too must
> authenticate the input. This is a problem with capabilities-as-data, but
> not object capabilities.

The general point about confused deputies is that (1) they perform
actions that their clients cannot perform, (2) incorrectly in response
to designations sent by some clients.

The last discussion raised point (1) -- that confused deputies
necessarily can perform actions that their clients cannot. I'm adding
point (2) -- that these actions are performed "incorrectly" only (in
fact, I'd say *by definition*) because either the service has failed to
perform input validation or because it shouldn't be responding to a
particular client -- the client shouldn't have gotten access to the

We all know that arguing whether the client should have access to the
service is very tricky -- it depends on whose behalf the client is
acting, for example, as Fred (Spiessens) elegantly points out in his
thesis. In an object-capability system, the service cannot defend
against this and can only perform input validation to protect itself.



More information about the cap-talk mailing list