[cap-talk] ... enforcement - hope? Capabilities vs. Systrace, others

[Jed Donnelley]

At 03:33 PM 9/28/2004, David Wagner wrote:
>Jed Donnelley writes:
> >OK, perhaps I'm not being fair to the ambient authority
> >model.  Let's see.  How to even try to describe it?  Firstly
> >there are users - whether human or not.  Every process
> >runs as a user and has the rights of that user.  Objects
> >in the system are owned by users.  Beyond that there is
> >the notion of groups and of 'other' (world) access.  A process
> >has the right to access an object with a specific access
> >right if that right is available either by virtue of the user's
> >ownership rights, the user's group rights, or world access
> >rights.  Does that about cover it?
>
>No, you're not being fair.  What you're describing is the Unix model.
>Unix is one example of an ambient authority system.  Not all ambient
>authority systems have these properties.
>
>For instance, Systrace is an ambient authority system where it is not
>true that a process runs as a user and has all the rights of that user.

Systrace (as I understand it - correct me if I go astray) has the whole
Unix ambient authority system behind it.  That is, a process runs as
a user and it gets at most the rights described above for the user
(with the same means for granting rights, etc.).  However, Systrace
adds another layer.  That is, it can allow (by policy) a process run
by a user to have essentially no initial rights, but to have any rights
granted by a policy file generated either interactively by the user or
otherwise - much like firewall (e.g. iptables) policy file.  As I understand
it the policy file is associated with the application by name.

To me the interactive nature of the system call trapping and policy layer
that Systrace adds to Unix (BSD) is a lot like the ZoneAlarm local firewall
mechanism for Windows (just curious, did either take inspiration from the
other?).

I wonder if you could help clarify something for me about Systrace?
For example in this httpd policy file example:

http://www.citi.umich.edu/u/provos/systrace/usr_sbin_httpd

I see:

native-kill: permit

Does that mean that the httpd process is allowed to execute the
Unix kill system call to kill whatever PID it chooses?  Specifically
is it not limited to "kill"ing the children that it creates?  If not,
doesn't that seem to be a bit of a concern?  Is it possible
to get around that issue?

Also when I see:

native-fork: permit

how do any such forked processes get started?  In particular do
they inherit the Systrace policy of the process doing the forking
(in this case httpd) or do they inherit the policy for the named
file that is forked or what?  This seems to be a somewhat sensitive
issue in the Systrace mechanism.

>It doesn't make sense to talk about "the" ambient authority model.
>There is no one ambient authority system.  Rather, the notion of "ambient
>authority" is a property that some systems possess and some don't.
>Similar comments apply to talking about "the" access list model.

I was trying to describe the base underlying property of ambient authority
systems.  While you say that I was describing the ambient authority
system of Unix, I think the description I gave would also apply pretty
well to NT or VMS, EXEC8, OS/360, or Tenex (Tops-20) or a number of
other comparable systems.  They all have the same basic problems to
deal with and all went about dealing with them in essentially the same way
(stretching my memory a bit).

>Similar comments apply to talking about "the" access list model.

I don't know of any OS that has ever been based purely on an access
list model.  However, there have been a number of systems that have
had an access list mechanism grafted onto them somewhat like Systrace
has grafted its system call trapping policies onto Unix.  In this case
I agree that there are probably not enough examples and not enough
commonality amongst the examples to generalize.  However, the
value that was touted for such access list systems (namely that
by looking at the access list you could determine who had access
to a resource and restrict access) strongly suggests that the access
lists be associated with the resource itself (e.g. a file) and that it list the
people allowed to access that resource.  Within that design constraint
there isn't too much room to wiggle.

Since we are covering access control models we might as well add in
the so-called "mandatory access control" approaches.  In my experience
this name is a poor choice as they all seem to be based on the notion of
levels (e.g. unclassified < secret < top secret) associated with objects
and subjects with various restrictions such as the inability to read
up (an unclassified process can't read a secret file).  Again these
mechanisms are typically add-on's to an ambient authority system
as I tried to generalize above.

>Don't tar all ambient authority systems, or all ACL-based systems, with
>the same brush.  They're not all equally bad.  Some of these systems
>do better than stock Unix, even though (as I have said before) they are
>not perfect.

In so far as the mechanisms are common I believe the systems tend to
have the same advantages and disadvantages.  While you seem to refer
to Systrace as an ambient authority system, I believe that, while Systrace
could not exist without the underlying ambient authority system of Unix,
the trapping/policy mechanism of Systrace is what provides its finer
grained access control.  Since it associates rights with a program it seems
a bit closer to a capability model in flavor - though of course very far from
providing the clean interfaces and dynamics of a native capability model.

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