[cap-talk] Where capabilities fall short - determining the invoker
toby.murray at dsto.defence.gov.au
Tue May 24 20:03:52 EDT 2005
Jonathan S. Shapiro wrote:
>>> MarkM and I believe -- but at this point it is ONLY a conjecture --
>>> 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.
Advanced Computer Capabilities Unit
Information Networks Division
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.
More information about the cap-talk