[cap-talk] Confused Deputies in Capability Systems - not
capability at webstart.com
Tue Feb 24 03:12:35 EST 2009
At 04:15 AM 2/23/2009, Sam Mason wrote:
>On Mon, Feb 23, 2009 at 03:36:48AM -0800, Jed Donnelley wrote:
> > Let's then take a modern example and see
> > how the capability communication model eliminates the possibility
> > of the Confused Deputy problem. Again from:
> > http://en.wikipedia.org/wiki/Confused_deputy_problem
> > we can consider the "cross-site request forgery (CSRF)":
> > http://en.wikipedia.org/wiki/Cross-site_request_forgery
> > problem.
>Thanks for the explanation Jed, it's perturbed my understanding of the
>confused deputy problem enough to rethink where the source of the error
>is in the original compiler example. I'd always thought it was with the
>compiler for allowing the bill to be overwritten, whereas it's really
>with the operating system for allowing this ambiguity to exist.
One way that helps me to clarify where the problem lies is to think
more generally about the designation by name communicated between
the requester and the server (the compiler in this case). Forget
the special nature of the billing file and just consider designation
of any other files that the requester and/or the compiler might have
access to. How does the communication system make clear to the server
(the compiler in this case) that a communicated designation (the name
of a file) specifies a file that the requester had access to. Such
a parameter may specify a file that the server does or does not
(yet) have access to. To me that aspect of things isn't significant.
What matters is the access that the requester had to begin with.
When considered in these terms it seems clear that it is only by
using a capability communication system that the mutually suspicious
requester and server can collaborate reasonably.
To me the rest are details. For example, when you say:
>In the compiler example this bug can be fixed a couple of ways:
> 1) the compiler shares responsibility with the operating system for
> checking security properties, namely that it ensures the output file
> isn't the same as the bill or any other state the compiler (but not the
> client) has access to
I don't think so. It may well be that the requester and the compiler
(server) share access to a file that might be a legitimate sink for
the requested output. The key aspect is that the communicated parameter
indicates an object that the sender had access to when sending. This
is exactly what a capability communication system guarantees, but which
no mechanism that uses names for designation can supply.
> 2) the operating system exposes the filesystem through capabilities and
> as a consequence the checking of security properties above will move
> into the operating system
>In the compiler example, it's therefore probably enough to check
>that the bill isn't overwritten by the output and to ensure that any
>temporary files go into a unique and empty directory.
I believe that any such efforts lead to unavoidable and increasing confusion.
It is only by communicating direct authorities that mutual suspicion
can be assured. If the requester has write access to a file and
directs the compiler to write into that file, well, regardless of
whether the compiler thinks of this as a billing file, the requester
could have written into it in any case.
>In the CSRF
>example, the problem gets a bit harder and the designation of authority
>probably needs to be made explicit somehow, capabilities seem to be a
>Have I got that about right?
Certainly in the CSRF case. In that case I believe (as I've described
elsewhere) using capability communication completely solves the problem.
Capability communication doesn't solve the general Trojan Horse problem,
but it does solve the Confused Deputy problem.
More information about the cap-talk