[cap-talk] Capabilities giving up control?

[Jed Donnelley]

On 1/20/2008 9:18 PM, Mark Miller wrote:
> On Jan 20, 2008 5:02 AM, John McCabe-Dansted <gmatht at gmail.com> wrote:
>> However I'd like to clarify one possible exception. We may casually say that
>> X can "influence" Y via a covert channel, but Y might not be in the
>> transitive closure of permissions. Or would we say that X and Y have
>> permissions to the shared resource used to implement the covert channel?
>>
>> However, we might still have  the case:  X -> Resource <- Y
>> But not: X -> Resource -> Y
>>
>> Or are permissions reflexive?
> 
> Ignoring the overt-vs-covert issue covered in my previous message, you
> touch on another distinction here which is related to but different
> than the permissions vs authority distinction. In an ocap system, if
> Alice has permission to talk to Bob, Alice can send Bob permission to
> talk to Alice.

I think it worthwhile to mention that in the above Alice
can send the Alice capability (or a Carol capability in
the more general Granovetter situation) directly to
Bob only if Alice has and uses a capability that allows
her to talk *directly* to Bob.

I mention this because I think it's important to make this
distinction to better understand the Horton "tunnel"s.

In the Horton situation, Alice has a capability to talk
to Bob, but that capability goes through Horton.  When
Alice sends the Alice (or Carol) capability to Bob, Bob
in fact receives a different capability, still generally
(depending on policy and state) with the authority to
talk to Alice (or Carol), but one that has been relabeled
as having been delegated from Alice (actually Alice's
"identity") to Bob (same ID notion) and is subject to the
Horton Policy Decision Point (PDP).

Since Horton retains the PDP, access by Bob to Carol can
go through any policy procedure needed.  With a mechanism
like Horton, one can retain this PDP flexibility (e.g. for
MLS or any such policy), while still only needing one level
of indirection from any subject to any object (e.g. unlike
always doing proxying or equivalently going through an
NDA as Toby and Duncan describe).

Of course in such a situation whatever mechanism is
in "Horton" becomes rather important.  Also, if it is
used a lot, one might find it worthwhile from a
performance viewpoint to push such a mechanism into
the kernel of the system (to avoid the cost of a
domain changes in so many circumstances).  This can
achieve to within epsilon of the performance of any
monolithic kernel, but still with an interface
that allows it to provide the modular flexibility
of the PDP, though it's likely not needed with a
language implementation.  This is also a case where
one can clearly see the distinction between "permission"
and "authority" played out.  By pushing "Horton"
into the kernel, Horton's PDP mechanism would become
part of the permission provided by the capability
rather than part of its authority (still seems
odd to me, but I 'get it').  In that case if
a user had their clearance reduced or a person
was removed from the executive board, the
permission to communicate might be removed
as well as the authority to communicate.

Referring to Table 8.1 on p60 of
> <http://www.cypherpunks.to/erights/talks/thesis/markm-thesis.pdf>,
> "current permissions" (CP) are not reflexive but a "topological bound
> on eventual permissions" (TP) is reflexive. In an ocap system, TP is
> the transitive *bidirectional* closure over CP.

I sent a copy of Table 8.1 in my "got it right?" message.
I got a rejection for size (which I guess Jonathan allowed
through) and the table went to:

http://www.eros-os.org/pipermail/cap-talk/attachments/20080121/1a2a060d/attachment-0001.obj

in case anybody wants to see just Table 8.1.  MarkM's
thesis is of course available through:

http://www.erights.org/talks/thesis/

to see the above table in context.

--Jed  http://www.webstart.com/jed/