[cap-talk] ... enforcement - ambient authority -
jed at nersc.gov
Wed Oct 6 16:23:29 EDT 2004
<somewhat delayed reply>
At 04:03 PM 9/29/2004, David Wagner wrote:
>Jed Donnelley writes:
> >>Systrace [is] an ambient authority system where the process does not
> >>run with all the rights of the user who started the process.
> >In that sense I don't consider it an ambient authority system.
> >It provides an additional 'filter' on the ambient authority, so it is
> >something more. As you say, though, a terminological nit.
>To continue the picking of minor nits:
>Then I think you are using the terminology in a way different from
>what I've seen others use (as far as I can tell). The benefit of using
>accepted terminology is that communication is often easier when we avoid
Of course. Since I'm new to the term I'll adopt the use you suggest unless
we hear from others.
>Based on what I've read here, the definition of "ambient authority system"
>on this list seems to be any system where a process has associated
>with it an implicit set of rights, where when the process performs
>some operation (e.g., makes a syscall), the reference monitor checks
>whether there exists any right in the processes' set that would permit
>the operation to succeed.
>In other words, ambient authority systems are ones where the process does
>not explicitly state which of its rights it is wielding (which of its
>rights it thinks demonstrates that the operation should be permitted).
>Rather, this is left implicit, and as a result the reference monitor has
>to guess at which right the process intended to use for this operation.
I'm afraid this does puzzle me a bit. Take the example (common and
to the point I would think) of a file open call. Naturally the program must
state what resource it's trying to open - namely the file whose name it
specifies. Are you distinguishing between the name and the right? Even
in a classical capability list system one might argue that an index (e.g. 5)
is just a name for the resource to be accessed. Of course such a system
provides a tremendous simplification with regard to access rights checking.
All the rights are in one simple place and referred to by a simple "name".
Still, the distinction from an ambient authority system is a bit lost on
me. I guess I was keying in on the inheritance of "ambient" authority -
e.g. in a fork or exec call. I don't recall, but I wouldn't be surprised to
see some capability systems with something comparable where a
fork copies or even shares the c-list of the caller - though it seems
somewhat nasty business. "just" a simplification to reduce overhead.
Even with such a simplification in a call I wouldn't consider a capability
system with such a call an "ambient authority" system. That term seems
to me to more strongly suggest a system in which processes pick
up a widely shared authority pool - e.g. the pool belonging to a "user".
Since I picked the term up from Alan Karp, perhaps he can explain it
and/or refer us to its origin. Where did you pick it up from David?
In doing a quick Google (the wonders of the age) I see Dean Tribble
takes credit for coining the term and describes a bit of his thinking at:
Jonathan Shapiro provides this clarification, coming close to what you
say above David:
"... MumbleSoft is an "ambient authority" system. Operations requiring
privilege do not explicitly designate the authority that permits that
OK, I can accept that terminology, though as can be seen from the
above and elsewhere it wasn't entirely intuitive to me. By that definition
Systrace is definitely an "ambient authority" system - even if each process
execution in principle has its own distinct authority set (provided by the
policy file). In the classical capability list system I guess one can say
that even if the index is a name for the resource, it is simultaneously
a name for the right to the resource (the great value of capability systems,
binding the name for a resource with a right to access the resource).
>At least, that's my understanding of the accepted meaning of this term
>among this community. (Caveat: I've learned this notion from others,
>so I could well have it wrong; if so, I hope others will let me know.)
>End of nit pick. Sorry for that. I hope I'm not beating a dead horse...
Perhaps I started using the term too much and too soon without a
thorough understanding. It definitely has an intuitive appeal. I hope
the above clarifies the preferred use of the term - though others should
of course feel free to chime in.
More information about the cap-talk