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

[Jonathan S. Shapiro]

On Mon, 2004-05-03 at 12:31, David Hopwood wrote:
> Jed Donnelley (by way of Mark S. Miller <markm at caplet.com>) wrote:
> > 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).

The problem you describe is real, but it is the effect rather than the
cause. The cause is that processes have no persistent identity. In
consequence, it is impossible in most ACL systems to establish an
association between processes and objects that survives restart. This is
why ACL systems universally fall back to principal ids rather than
subject ids.

One way to think about a principal id is that it defines an equivalence
class on subject ids. That is, it is a "force divider" in the
expressiveness of the protection system.

shap