[cap-talk] non-delegatability in OCap systems, e.g. Horton
Jed Donnelley
capability at webstart.com
Sat Jan 19 14:28:12 EST 2008
cap-talk,
In light of recent discussion, I thought it
might be worthwhile to make a simple observation
about "delegatability" in object capability
systems (even without the sort of NDA
that Toby and Duncan describe):
We of course understand that capabilities
can only be delegated through other capabilities.
So, for example, if Alice has a capability to
Carol and a capability to Bob, then Alice
can send the Carol capability to Bob, the
typical Granovetter diagram:
http://www.erights.org/elib/capability/ode/overview.html
which I'll abbreviate in textual form as:
Alice -> Bob
\
\> Carol
goes, after Alice's delegation, to:
Alice -> Bob
\ |
\> Carol
However, if Alice's only capability that
might effect communication to Bob is in
fact a capability to something like a
Horton tunnel:
Alice -> Horton -> Bob
\
\> Carol
then the Horton Policy Decision Point can
make any sort of policy based decision
about the Carol capability flowing through
it. Horton could, for example, think
(anthropomorphically again):
I know the Alice identity
< for more identities,
see the Horton paper:
http://www.erights.org/elib/capability/horton/
the "identity" that Horton knows has
nothing to do with Alice's active object
or address or anything like that. It's
effectively just a label that was put
on the capability that Alice had - in this
case to Bob - through Horton>
and I know Alice's "clearance". I know Bob's
identity and Bob's clearance. I can ask
Carol what the "classification" or sensitivity
is of the object whose capability Alice
is trying to send through my tunnel
to Bob.
At that point Horton can make any sort of
policy based decision and act on that decision
regarding the communication.
Generally Horton will simply effectively
'membrane' the capability and pass it on
to Bob:
Alice -> Horton -----> Bob
\ |
\ Horton
\> Carol <-/
This leaves Horton in the position of
being able to dynamically make access
decisions - e.g. if the environment
changes (e.g. Bob is no longer on the
executive board).
I just wanted to note the obvious, that
in some sense one can regard the above
as a mechanism for doing "non-delegation".
Horton can block Bob's access to Carol
through the Horton tunnel.
From Alice's viewpoint, such blocking
may be "mandatory" if she has no other
way to communicate to Bob or
"discretionary" (though still with
what AlanK refers to as Voluntary
Oblivious Compliance) if Alice does
have other ways (other capabilities)
to communicate to Bob.
However, the above sort of "non-delegation"
is not being done at the base level of
object capability communication. It's
being done at a higher level. To make
it "mandatory" requires confinement
(in this case of Alice). This is the
difference from the NDA mechanism that
Toby and Duncan discuss in their paper:
"Non-Delegatable Authorities in Capability Systems"
By Toby Murray and Duncan Grove
(to appear in the Journal of Computer Security)
http://web.comlab.ox.ac.uk/oucl/work/toby.murray/papers/NDA.pdf
I don't know if the above helps. I
consider it sort of the "Elephant in
the Room", but I just wanted to make
sure I clarified what seems obvious
to me.
--Jed http://www.webstart.com/jed-signature.html
More information about the cap-talk
mailing list