[cap-talk] Re: "capabilities" as data vs. as descriptors - OS security discussion, restricted access processes, etc.

[Jed Donnelley]

At 09:31 AM 5/3/2004, David Hopwood wrote:
>Jed Donnelley (by way of Mark S. Miller <markm at caplet.com>) wrote:
>>At 11:25 AM 4/27/2004, Jonathan S. Shapiro wrote:
>>>The reason that the safety problem is decidable in the capability case
>>>is that the transmission of authority is governed by authority. That is,
>>>in order for A to send some capability X to B, A must already be in
>>>possession of a send capability to B.  This is the result from the
>>>Jones, Lipton, Snyder work on capability safety.
>>>
>>>The reason that the safety problem is decidable and unsafe in ACL
>>>systems is that no such restriction on transmission exists. In an ACL
>>>system, A can transmit an authority to B **whether or not A holds an
>>>authorized communication channel to B**.
>>Good point (regardless of the term "safety").  ACL based systems really
>>seem to get messy (to me) because of their dependence on the notion
>>of "subject".  When that subject is a human being then I throw up my
>>hands entirely.  However, if a subject is a process then I certainly think
>>the notion (as I understand it above) of "safety" can be enforced in an
>>access list based system.  Namely, the server of the resource (who
>>knows who has access) can simply deny any request to add a process
>>to an access list unless the requesting process is on the access list.
>
>In the ACL model being discussed, and in most real-world ACL systems,
>this isn't possible. There is a primitive that allows the owner of a
>resource to add a *named* principal (e.g. by UID) to the resource's ACL,
>regardless of whether the owner has an authorized channel to that principal.
>The use of this primitive can't be intercepted by the server of the resource
>(not the same thing as its owner).

Whew, this seems to me to be getting a bit messy.  The part I don't understand
above is when you say "regardless of whether the owner has an authorized 
channel
to that principal."  You seem to suggest the distinction between the owner
of a resource and a process that simply has access to the resource by virtue
of being on the ACL?  I thought what we were discussing was the problem
of keeping process A (who does not have access to the resource because
it isn't on the ACL) from adding another process B to the ACL.  Are you saying
A could still do so if it somehow represented the owner of the resource?  At
that point I think we are starting to mix human access with process access
and seemingly with the same ACL mechanism?  Sorry, I don't get it.

Certainly the ACL mechanisms in Managing Domains:

http://www.webstart.com/jed/papers/Managing-Domains/

(there are at least two there, the pure ACL mechanism and the encrypted 
address protection mechanism)
do not allow a process to transfer access rights to a resource unless that 
process
has access to the resource itself (though watch out for the "Reflection 
Problem" there, as
noted a bug in the DCCS proposed implementation).

Perhaps I don't know what is encompassed by the phrase "real-world".  Does 
it mean systems
that are using human beings as the subjects for the access lists?  In that 
case of course
things break down.

--Jed http://www.nersc.gov/~jed/