Confusing The Deputy (was: Split Capabilities: Making Capabil ities Scale)

[Karp, Alan]

> -----Original Message-----
> From: Jonathan S. Shapiro [mailto:shap@eros-os.org]
> Sent: Saturday, July 15, 2000 4:46 PM
> To: Karp, Alan; 'Mark S. Miller'
> Cc: 'Norman Hardy'; e-lang@eros-os.org; Brian Marick
> Subject: Re: Confusing The Deputy (was: Split Capabilities: Making
> Capabilities Scale)
> 
> 
> > A particular threat occurs for proxies, those deputies that can be
> confused
> > because they have more authority than the client on whose 
> behalf they act.

Agreed.  That's why the proxy protection domain has fewer privileges than
any other client except the PD given out on an initial connection.

> 
> This is one of the compelling examples for why authority should be
> designated with each operation. When a proxy has ambient 
> authority, it is
> very easy for the application software to become broken over 
> time due to
> maintainance errors. Similar effects have been observed with 
> setuid/setruid
> in sensitive UNIX applications.

Whenever we can, we have the client delegate its capabilities to the proxy.
Then all the proxy has to do to avoid being fooled is to drop these
capabilities when it's done with the request.  Alternatively, the client can
protect itself from the deputy being confused by revoking the delegation.
E-speak Beta 2.2 makes this last easy.

There are times, however, when we can't have the client delegate authority
to the proxy, at least not directly.  This situation happens when the client
is not part of the e-speak environment.  For example, we allow a client with
an HTML browser to use e-speak services.  If the client has any security at
all, it's SSL.  The WebAccess proxy uses its authentication mechanisms to
identify the client and associates each identity with a protection domain.

In both cases, there is risk, but we've made every attempt to minimize what
the proxy needs to get right to avoid problems.  In the case described in
the first paragraph, it is dropping capabilities when the request is done.
In the one in the second paragraph, it is getting the mapping between
identity and protection domain right.

> 
> > ...the proxy can maintain a separate key
> > ring representing the authority for each client.
> 
> This is better than ambient authority, but will still suffer from
> maintainance related failures. Also, note that the cost of proxy just
> tripled, as the proxy must now do
> 
>     set effective key ring
>     perform operations
>     set generic key ring
> 
> around the proxy operations. It may be that designating the 
> capability in
> the first place is in practice more efficient, but I'm not 
> sure of that.

Actually, every request is associated with a list of key rings, the
mandatory key ring being included by default.  Hence, there is no need to
set an effective key ring.  However, if the proxy is impersonating the
client, there is a need to switch protection domains.  Currently, we require
the 3 steps you list (with PD instead of key ring).  However, message
ganging is in the archtitecture (It's just not implemented yet.), so the 3
requests can be handled in a single message to the engine.

> 
> shap
> 

_________________________
Alan Karp
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278