[cap-talk] Use-case: hybrid capability systems

Jed Donnelley capability at webstart.com
Tue Feb 5 01:46:11 EST 2008

At 07:26 PM 2/4/2008, John McCabe-Dansted wrote:

>On Feb 5, 2008 9:36 AM, Jed Donnelley 
><<mailto:jed at nersc.gov>jed at nersc.gov> wrote:
>On 2/4/2008 11:24 AM, Jonathan S. Shapiro wrote:
> >   C1. No solution requiring new storage to be allocated during every
> >       communication between the authorized parties is practical.
> >
> >   C2. No solution requiring a mediator is admissible. Rationale:
> >       we cannot afford to more than double the cost of every object
> >       invocation. Solutions that are able to perform a mediation check
> >       and somehow cache the result in order to achieve reasonable
> >       efficiency are acceptable.
> > Anybody see a way to do this with a pure capability design?
>Interesting.  Of course a scenario like above is exactly
>where I've been shooting at with the Horton mechanisms.
>The only point where Horton has problems with the above
>are at C1 and possibly at C2 (though as you say, I
>believe this performance issue can be optimized away).
>The reason a Horton sort of approach fails C1 is that
>it must keep track of the delegation path - e.g. to
>protect from confused deputies if for no other reason,
>but of course there are other reasons such as the
>typical requirement for logging for auditing.
>AFAICT, We don't really need to store the whole delegation path; E.g.
>    A->B->A->B->A->...B->A
>However we may choose to only store the fact that A->B, and later B->A.

I think you're probably right about the above.  I haven't thought
it through fully.  From the examples that I've gone through (e.g.
the MLS example) I would say that how much needs to be kept depends
at least to some extent on the policy implemented by the PDP.  At
the moment I can't imagine a policy that wouldn't permit collapse
of the sort of back and forth delegation between identities that
you give above.  In fact for all the policies I've played with
all that is really needed is that the list include all the
identities that were part of the chain - regardless of order
or who delegated to who, your point I think:

>Also for many purposes it is sufficient to know that the capability 
>is tainted by {A,B}

Who delegated to who I think is more importing for logging
and auditing functions.  I think these are important, but
they make it difficult to enforce a tight constraint like
C2 - no storage allocation.

>This means that only a handful of unique Horton capabilities would 
>need to be allocated and constructed, even though the capability 
>gets passed back and forward thousands of times.

I think that's right, but I didn't want to claim it
without further thought.  Thanks for sticking your neck
out ;-)

>This seems like more of a problem with micro-kernels than 
>capabilities. With ACLs we still need the ACL manager to mediate 
>requests. Most ACL systems build the ACL mediator into the kernel so 
>the cost is no more than a function call. Conceptually, we could 
>also put a Horton based mediator into  the same address space as a 
>cap-based kernel.

Lovely.  A point I was going to make but left out
because I've been writing way too much to the list
lately.  In our NLTSS system implementation at one
point we pushed some services into the "kernel",
without changing the interfaces, in order to
improve performance (2x improved latency for some
requests).  If we were doing something like that
today we might use language enforcement (e.g. Joe-E)
in the kernel to try to keep some protection, but
I agree with your point that with something that is
being depended on so much like a Horton implementation,
issues like domain changes going into and out of
Horton may provide opportunities for optimization.

Of course implementations will vary.  I've got a
little experience about where Jonathan is coming
from regarding Coyotos that suggests that some
of his issues (e.g. C1) may be tighter constraints
that they would be in most of my implementation

--Jed  http://www.webstart.com/jed-signature.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20080204/493c2c5f/attachment.html 

More information about the cap-talk mailing list