[cap-talk] More Heresey: ACLs not inherently bad

[Marcus Brinkmann]

At Fri, 19 Sep 2008 10:20:35 -0700,
Jed Donnelley <capability at webstart.com> wrote:
> 
> At 06:03 AM 9/19/2008, Jonathan S. Shapiro wrote:
> >On Thu, 2008-09-18 at 17:26 -0400, Sandro Magi wrote:
> >...
> > > When creating a principal, we communicate with the ACL service through a
> > > management facet; creating a principal returns a capability with a
> > > protected payload naming that principal (call it an ACL key).
> >
> >This is definitely a feasible way to go.
> 
> An unworkable way to go - if I'm understanding it right.  With such
> a mechanism every time there is a request, one of these "ACL key"s must
> go along to authorize access.  If a process/active object wishes to
> send the authority to access a file to a compiler deputy, how can it
> do so without sending the ACL key along?  If it does so then the
> compiler server can act with that principal authority.

There are two possible solutions to this.

1. If there is a means to identify the sender of a request (for
example by unique unforgeable sender process IDs), a new ACL key can
be derived that is "tagged" with the process ID of the deputy.  As a
matter of policy in the ACL service, "tagged" ACL keys can only be
read out by the process with the ID in the tag.  Thus, the deputy can
not use this ACL key with any other process.

This is comparable to requiring an ID card or passport when picking up
a parcel, and only delivering the parcel to the intended recipient.
The post office agent implements the ACL service in this analogy.

I designed this solution for a capability system on the L4
microkernel, X.2 draft specification.  That specification had
compulsory, kernel-enforced sender process IDs in IPC calls.  It was
never implemented, though.

2. In the absence of such tags, there is a different method, but it
requires an eq? operator on capabilities and asynchronous operations.
The process creates a dummy capability that is called a "rendezvous"
capability.  The client makes a call to the ACL service, passing the
ACL key and the rendezvous capability as arguments (alternatively, the
ACL key interface could provide such a call).  Asynchronously, the
client also makes a call to the deputy, passing the rendezvous
capability along with whatever parameters are required for the actual
request.  The deputy then calls *its* ACL service, passing the
rendezvous capability as an argument and also a capability that should
be returned to the process.  The ACL service can now use the eq?
operator to match the call from the process and the call from the
deputy by the rendezvous capability.  It (the ACL service) then
replies to the process with the capability given by the deputy, and
copies the data of the processes' ACL key into the reply to the
deputy.

The second solution was designed by Thomas Bushnell for the GNU/Hurd
system and has been implemented and used in the GNU/Hurd to implement
an "auth" server implementing support for POSIX-style user and group
IDs.  It is flexible enough to allow proxy-ACL services that implement
various interesting policies, such as monitoring or "fake root" IDs,
without compromising security.  It is documented in great detail in

@article{walfield07hurd-critique,
  author = {Neal H. Walfield and Marcus Brinkmann},
  title = {A critique of the GNU hurd multi-server operating system},
  journal = {SIGOPS Operating System Review},
  volume = {41},
  number = {4},
  year = {2007},
  month = jul,
  issn = {0163-5980},
  pages = {30--39},
  doi = {http://doi.acm.org/10.1145/1278901.1278907},
  publisher = {ACM Press},
  address = {New York, NY, USA},
}

online also at 

http://www.walfield.org/papers/200707-walfield-critique-of-the-GNU-Hurd.pdf

Thanks,
Marcus