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

[Jed Donnelley]

At 06:26 PM 2/8/2008, John McCabe-Dansted wrote:
>On Feb 7, 2008 2:53 PM, Jonathan S. Shapiro 
><<mailto:shap at eros-os.com>shap at eros-os.com> wrote:
>On Wed, 2008-02-06 at 14:07 +0900, John McCabe-Dansted wrote:
>...
>Capabilities contain no information about who holds them. In
>
>
>In general. But we are discussing Horton based systems, and AFAICT 
>Horton keeps track of which compartment holds which capabilities.
>
>consequence, a pure capability system must keep track of the chain of
>capability transfers in order to implement this type of revocation.

I think you may both be saying the same thing using different words.

...

>This would still allow us to:
>   - revoke all access held directly by Bob (Bob has left company)

If you want to do the above then the Horton policy should be set
up to also do this:

>   - revoke all access held by Bob and anyone Bob has delegated to 
> (We discover that Bob is a black-hat)

or you will end up with possible confused deputies as we've discussed
recently on cap-talk.

>So there are really two problems with a chain structure: the amount of
>storage involved and the problem of revocation.
>
>It is possible to imagine a design in which some sort of capability
>exchange protocol is used at compartment boundaries so as to ensure that
>each compartment holds a copied capability C' that is independent of the
>origin capability C for purposes of revocation. It is not immediately
>
>
>Doesn't Horton already do this?
>
>clear how to do this without supporting protocol in every object
>implementation. Unfortunately, the objects themselves are not trusted
>and so it is difficult for the per-compartment reference monitor to call
>them safely in order to exercise the exchange protocol.

"Horton" of course does what you see in the reference implementations.
I'm afraid I don't understand well enough what you are asking to answer
your question.

--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/20080208/5f33a443/attachment.html