[cap-talk] Documentation and the "Access Propagation Fear"

[Jed Donnelley]

On 3/20/2008 7:17 PM, David-Sarah Hopwood wrote:
> Jed Donnelley wrote:
>> http://www.cs.utah.edu/flux/papers/micro/node4.html
>>
>> with this:
>>
>> "Though popular, capability mechanisms are poorly suited to
>> providing policy flexibility, because they allow the holder
>> of a capability to control the direct propagation of that
>> capability, whereas a critical requirement for supporting
>> security policies is the ability to control the propagation
>> of access rights in accordance with the policy. The enhancements
>> introduced by Hydra
> 
> This is probably referring to 'EnvRts' [*] (which is useless as
> a security mechanism, and interferes with delegation)...

Around and around we go.  EnvRts is our old friend (from your
reference below) "do not delegate" by another name (actually
it's opposite - without EvnRts a capability can't be delegated).

>  > and KeyKOS
> 
> but I have no idea what this is referring to. Anyone know?

I'm also interested in the answer to the above.

>> are intended to limit such
>> propagation, but the resulting systems still generally only
>> support the specific policies they were designed to satisfy,
> 
> I really don't know what to say to this. It's a particular strength
> of capability systems that they can enforce unanticipated policies
> outside the kernel -- 'Paradigm Regained' has a good discussion of
> that.

I think what he is saying is that, regarding delegation, the
only policy a capability system can support is fixed by a
mechanism like the EnvRts mechanism.  That is, with EnvRts
a capability can be delegated, and without it not, but no more
complex policy (e.g. it can be delegated to somebody on the
board, but not to somebody not on the board) can be supported.

<aside - the old question of how EnvRts gets turned off
in a capability is a well known question, that amounts
to the "pass once" mechanism from Demos.  I'm not going
to take the time here to research how that's done for
Hydra.>

 From my perspective this is exactly where Horton comes in.
With Horton the delegation policy isn't fixed, but rather
is determined by whatever policy is put into the policy
decision point in the tunnels.  I believe that Horton
demonstrates (if it wasn't obvious before) that capability
systems can provide support for policies as rich (isomorphic to
actually) as ACL-based systems can - at the level of
communication between identities, which is all ACL-based
systems provide.

>> at the cost of significant complexity that diminishes the
>> attraction of the capability model in the first place."

and without any additional complexity - at least in the
delegation mechanism.  That stays the usual send a
capability in a message (invisibility of Horton tunnels).
There is the additional complexity in whatever policy
is deployed and in managing that policy, but of course
this must be there in any case.

> [*] http://www.google.co.uk/search?q=site%3Aeros-os.org+EnvRts

which I think provides a specific and detailed answer
to Stephen D. Smalley.

--Jed  http://www.webstart.com/jed/