[cap-talk] In Defense of Identities - not

[Marcus Brinkmann]

At Wed, 06 Dec 2006 15:44:53 -0500,
"Jonathan S. Shapiro" <shap at eros-os.com> wrote:
> 
> On Wed, 2006-12-06 at 14:40 -0600, Eric Jacobs wrote:
> > On Wed, 06 Dec 2006 11:46:17 -0500
> > "Jonathan S. Shapiro" <shap at eros-os.com> wrote:
> > 
> > >   3. In the absence of a trusted service, it is exceptionally
> > >      difficult to get transitivity of revocation right. The simple
> > >      cases are simple and the hard cases are impossible. Consider:
> > > 
> > >         c1->someOperation(...arg...) => c2
> > > 
> > >      the decision to wrap the 'c2' capability depends a great deal
> > >      on what 'someOperation' does.
> > 
> > What would such a decision depend on? Is there an advantage to sending back an unprotected capability?
> > 
> > -Eric
> 
> Oh very definitely there are advantages to not wrapping:
> 
> 1. Introducing a wrapper is incredibly expensive (thousands of cycles).
> 2. Introducing a wrapper requires storage allocation. This raises
> accounting issues that perturb APIs.
> 3. Introducing a wrapper requires a capability lookup to see if another
> wrapper has already been introduced for C2 so that the results of EQ can
> be preserved.
> 4. Because of EQ, it's unclear what to do when C1==C2 and C1 was not
> wrapped.
> 5. If the responsibility for wrapper introduction lies in the object
> servers, then our story for revocation only works for objects whose
> implementation we trust.

Number 1 is an implementation note that may not hold true for some
implementations, in particular ones derived from the L4 mapping model.
L4.sec design also has some novel ideas how to solve number 2.

I am not sure that number 3 and 4 are a real problem.  Delegations
open up more varied possible semantics for eq?, true, but any
particular semantic may be sufficient for all relevant use cases.
Just because there is a choice doesn't mean that no alternative is
appropriate for any given system.

I agree with 5, but again, it may not be an issue, depending on
implementation details (both in the kernel and the operating system).

When you wrote:

  3. In the absence of a trusted service, it is exceptionally
     difficult to get transitivity of revocation right. The simple
     cases are simple and the hard cases are impossible. Consider:

        c1->someOperation(...arg...) => c2

     the decision to wrap the 'c2' capability depends a great deal
     on what 'someOperation' does.

I hoped that you could give some specific examples for "someOperation"
where the semantics should be "no wrapping", or where the semantics
are not clear.

Thanks,
Marcus