[cap-talk] Confused Deputies in Capability Systems

[Toby Murray]

On Wed, 2009-02-11 at 17:42 +0000, Karp, Alan H wrote:
> Toby Murray wrote:
> > 
> > Could you elaborate? How would you modify my web-browser-on-a-cap-OS
> > example to avoid the confused deputy, or as you say "to perform the
> > mapping [from URLs to capabilities] in the invoking context [i.e. taht
> > of the web-browser rather than the network service]"?
> >
> Here's what we did for legacy applications in e-speak.  We set up a proxy for each external user at the gateway into the capability system.  Each proxy had the clist for its user.  The proxy mapped requests in the legacy API, which used strings to denote resources, into the e-speak API, which used capabilities.  Since the proxy only had access to the user's capabilities, there was no way for the users to designate rights they didn't have.  The worst thing the user could do was misuse one of its own rights.
> 

I understand completely.

I suggested something similar with the web-browser example: have the
network service not hand back raw HTML but instead rewrite all URLs in
the HTML to c-list indices and return capabilities to each resource.

This works for something like HTML but not for dynamically generated
URLs as you might have in JavaScript. The problem of mapping
non-authority-carrying-designators to capabilities when passing back
executable code is probably undeciadeable in general. I think there will
be corner cases like this that are hard to deal with in any large-scale
ocap system. I hope I'm wrong.

Cheers

Toby