[cap-talk] Where capabilities fall short - determining the invoker

[Toby Murray]

Jonathan S. Shapiro wrote:

>>> MarkM and I believe -- but at this point it is ONLY a conjecture -- 
>>> that
>>> all of the policies that are actually enforceable can be expressed
>>> cleanly with capabilities, and that none of the policies that don't
>>> actually work can be expressed cleanly with capabilities.
>>
I'm wondering if someone could please help me to understand exactly what 
Jonathan means in the above by quickly examining a couple of examples.

Example 1 deals with this part of the statement:
"all of the policies that are actually enforceable can be expressed
cleanly with capabilities:

In this example, Alice has some authority on Bob. Alice can also 
communicate with Carol. Since Alice can proxy for Carol, Carol has (at 
least) the same authority over Bob that Alice does, if Alice is willing 
to play along. Therefore, we cannot enforce that Carol has no authority 
over Bob. We can enforce that Alice has discretion to allow Carol 
authority over Bob.

Capabilities cleanly express this policy. It is also enforcable.

Example 2 deals with the second part of the statement:
"none of the policies that don't
actually work can be expressed cleanly with capabilities"

We'll use the same example. This time, we want to prevent Carol from 
having any authority over Bob, but we still wnat to allow Alice and 
Carol to communicate. Of course this policy is unenforcable in any 
system since Alice can proxy for Carol. It is also unable to be 
expressed (cleanly) with capabilities.

Do these two examples illustrate these two parts of the statement?

If so, I'd like to present a third example. In this example, I'll use an 
"object-capability" system as the model (eg. E) and hope that I haven't 
lost generality. It comes back to Jed's points about identity.

The policy says "we don't care who has access to Alice, but we want 
Alice to be able to tell us, at any time, who has made direct method 
invocations on her".
This is enforcable if Alice can determine the source of method 
invocations. Furthermore, E could support this sort of thing (I don't 
know if it does) by having the local language implementation tell us 
which object invoked a method and by levereging the TLS-like 
authentication between vats (presuming we trust remote vats -- if we 
don't trust a remote vat, it doens't matter which object on that vat the 
call came from anyway, so the TLS-like negotiation is enough).

I find this example of being able to determine who invoked a method to 
be my current puzzlement over capability systems. Is it actually 
enforcable? (ie. can we reliably determine the source of method 
requests?). If so, then it surely gives us some extra expressiveness 
that traditional capability systems like E do not.


-- 
Toby Murray
Software Engineer
Advanced Computer Capabilities Unit
Information Networks Division
DSTO, Australia

IMPORTANT: This e-mail remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the
Crimes Act 1914. If you have received this e-mail in error, you are
requested to contact the sender and delete the e-mail.