[cap-talk] Re: "capabilities" as data vs. as descriptors -
OS security discussion, restricted access processes, etc.
jed at nersc.gov
Mon May 3 23:43:51 EDT 2004
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
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:
(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
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.
More information about the cap-talk