[cap-talk] Confused Deputies in Capability Systems

[Bill Frantz]

toby.murray at comlab.ox.ac.uk (Toby Murray) on Wednesday, February 11, 2009 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]"?

This question is of particular relevance, since I am now working on a HTTP
server for CapROS. In its current incarnation, it is intended to implement
file up/down load, using Swiss numbers to identify the data objects we are
calling "files". Currently in my test-bed system, you can use curl to up
and down load files, using PUT and GET respectively.

It breaks the URI down as:

part       example        Use

Scheme     https:/        Makes clients do the right thing in connecting.
Authority  /foo.bar       Totally ignored. Clients may use it for a local
                          file name
Query      ?390232        Swiss number. Used to access "file" object in a
                          local directory.
Fragment    -na-          Someday a Javascript client-side script may move
                          the fragment of a URI to the query bypassing
                          browser's love of leaking web keys through
                          features such as "Referer".

Since all data is downloaded using "Content-type: text/text", Firefox at
least doesn't interpret the data as HTML.

While I don't think Toby's example is a classic "Confused deputy", I do
think it is an important class of bug which needs to be well described and
named. I would certainly like to avoid being exploited by it.

(I would prefer SCP or SFTP for file transfer, but their wire protocols are
very poorly documented, and they seem to require something like a unix
shell on the server side. With this level of dangerous squishiness, I ran
screaming for the relatively well documented http. Out of the frying pan
and into the fire.)

I could see this HTTP server growing up to be a web server UI (since HTML
is a fairly rich UI tool kit. Then I would want to adopt Alan Karp's 
suggestion:

>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.

The major question with this approach is how you connect a user with the 
correct capability directory and, given the "connectionless" nature of 
http, keep the session associated with the correct directory.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | The first thing you need when  | Periwinkle
(408)356-8506      | using a perimeter defense is a | 16345 Englewood Ave
www.pwpconsult.com | perimeter.                     | Los Gatos, CA 95032