[cap-talk] capabilities Q, SetUID and ambient authority problems

[David Hopwood]

Jed at Webstart wrote:
> At 08:31 AM 6/16/2006, Karp, Alan H wrote:
>>Jed wrote:
>>...
>>
>>>Probably they'd also zone out if you mentioned "suid" programs,
>>>but to me that seems a key place where confused deputies arise
>>>in today's computer systems.
>>
>>Then I'd have to explain what suid does, why you'd use it, blah blah
>>blah.  Remember, few of the people I present to speak Unix.
> 
> Right, but remember what the basic point is that we're trying to get
> at (if I have this right), namely the added value that comes from
> using a POLA (e.g. almost necessarily "capability") approach to
> authorization rather than "ambient authority" (users, groups, etc.).
> 
> The fact is that something like SetUID is the only means feasible
> for any sort of "deputy" to work under an ambient authority model.

Consider a web server. It takes requests from the network, and uses its
own authority to read the files that are to be served. It also needs to
read its configuration files.

The code that serves a particular request has to avoid inadvertently
serving a configuration file. In a typical non-cap system, the only way
to ensure this is for the server to perform an additional check on the
URL or the filename constructed from it; flaws in this check (particularly
failure to check for various encodings of "..") have been an *very*
frequent cause of security bugs in web servers. Although this differs
somewhat from the original confused deputy attack, the server is still
confused in a similar way -- it may open a configuration file on behalf
of a client that should not have the authority to do that. This example
does not depend on setuid.

A typical cap system, OTOH, would support first-class namespaces [*],
so that the server can look up the URL path in a namespace that contains
only files that should be served. Also, the server would be more likely
to be split into domains such that the domain which is serving a particular
request does not have direct access to any config files -- although it can
still have access to any information read from them that it needs.


[*] Granted, there are also non-cap systems, such as Plan9, that
    support first-class namespaces.

> I think it's difficult to really understand the value of the
> capability/POLA model of computing unless you can
> effectively contrast it with the necessary awkwardness
> of even very simple mixing of authorities with the
> ambient authority model.  That means looking at the
> problems with SetUID as that is the dominant means
> for dealing with such mixing in the ambient authority
> world.

I don't think anyone is suggesting that problems with setuid are
not important; just questioning whether they should be discussed in
an *introduction* to capabilities.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>