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

[David Hopwood]

Jed Donnelley wrote:
> At 09:31 AM 5/3/2004, David Hopwood wrote:
>> Jed Donnelley (by way of Mark S. Miller <markm at caplet.com>) wrote:
>>
>>> 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?

In Posix, Windows NT, and most other implementations of ACLs, each
resource has an owner, and the owner is the only subject that can directly
change the ACL (ignoring superusers/Administrators and other complications).

However, that's not the important thing; it wouldn't matter if there
were no distinction between owners and other subjects that have access.

 > 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.

No, that's not the problem. The problem is that A, which does have access,
can add B to the ACL, even though A doesn't have an authorized channel to B.

> Perhaps I don't know what is encompassed by the phrase "real-world".

Implemented systems in actual use.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>