[cap-talk] ... enforcement - ambient authority - definition?

[Jed Donnelley]

<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
>non-standard usages.

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:

http://zesty.ca/zest/out/msg00139.html

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

from: http://zesty.ca/zest/out/msg00181.html#msg181-sec0

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.

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