[cap-talk] Confused Deputies in Capability Systems
naasking at higherlogics.com
Fri Feb 6 09:49:25 EST 2009
I think the last discussion of confused deputies indeed concluded, as
you say, that object-capability systems are vulnerable to the confused
deputy when performing a rights amplification. However, rights
amplification should be less common than typical capability invocation,
and should be carefully guarded due to the increased potential for
damage, which is why it is often an explicit operation. This is what
provides the safety against confused deputies in object-capability
systems, and this is the benefit of capabilities.
An object-capability program that uses no rights amplification is not
subject to confused deputies. Programs that do perform rights
amplification must carefully vet arguments to avoid confused deputies.
Systems with implicit rights amplification, like Alan's package-scoped
Joe-E example [1,2], are also clearly subject to confusion and must vet
arguments as well (other solutions to this one interest me a great deal).
Given rights amplification is often an explicit operation, is more
really required? On the ACL side, if ACL systems had a way to wrap input
parameters in a "vetted" type so the server accepts only an authorized
path string from clients, then the same resistance to confused deputies
are enjoyed for ACLs (the vetted type performs the access check before
it is sent to the service). Assuming the service also doesn't perform
some other type of rights amplification of course.
Toby Murray wrote:
> Following the recent discussion of confused deputies in the context of
> Tyler's "ACLs Don't" paper, I wanted to talk a bit more about these in
> the context of object-capability systems.
> A confused deputy is any program that can be confused into using part of
> its authority, given to it for one purpose, for a different purpose,
> usually on behalf of some (malicious) client. A general symptom of a
> confused deputy is that the malicious client has excess authority.
> I'd like to try the unconventional argument that confused deputies could
> be common-place even in object-capability systems that we traditionally
> believe make them much harder to construct. This argument is premised on
> the (common, especially by non-capability folks) observation that the
> prototypical confused deputy attack in the ACL model arises because the
> Compiler does not perform input validation (by checking that the string
> that the User passes it does not designate its billing file).
> My argument is that confused deputies can arise whenever a service in an
> object-capability system similarly fails to perform input validation on
> the capabilities it is passed (rather than arbitrary strings), in the
> case that those capabilities are more powerful in its hands than in
> those of its clients (e.g. via rights-amplification).
> The only means of protecting itself against such attacks is for the
> service to perform input validation on capabilities it is passed -- this
> is why object-cap systems include capability-authentication mechanisms
> primitively (e.g. trademarks in E, Cajita, KeyKOS and EROS, static
> checking of final types in Joe-E etc.).
> Are there other ways to defend against these capability-based confused
> deputy attacks? If not, then the argument that the most appropriate way
> to deal with them in IBAC systems is through input validation (rather
> than transforming these systems to object-capability systems) seems more
> cap-talk mailing list
> cap-talk at mail.eros-os.org
More information about the cap-talk