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

[Marcus Brinkmann]

At Wed, 24 Sep 2008 22:54:11 +0000,
"Karp, Alan H" <alan.karp at hp.com> wrote:
> > Karp, Alan H wrote:
> > > David Wagner wrote:
> > >> So my hypothesis is that the more seriously you take the principle
> > >> of least privilege(authority), the more you have to be careful about
> > >> confused deputy bugs.
> > >
> > > I'm not so sure.  The compiler service necessarily needs the
> > authority
> > > to read and write every file the invoker might specify as parameters.
> >
> > No, if the parameters are capabilities then each instance of the
> > compiler
> > only needs the authority passed by its actual parameters.
> >
> Mea culpa.  I should have made it clear that I was talking about the ACL case.

Frankly, I never really understood the strong dichotomy between ACL
and capability systems.  In my mental model, in the "ACL case" the
user still passes the authority to read and write the user's file as
parameters to the compiler invocation, implicitely as part of the
process state before the exec().  That the authority is passed
implicitely rather than explicitely is just an artefact of the
interface.  This mental model is not apparent when looking at Unix
because in Unix, many of the subtleties of this model are degenerate
and thus invisible.

The problem in Unix is that it is impossible to prevent this implicit
delegation from happening, because chroot() is a restricted operation.
But it is only restricted because it turned out to be hard to retrofit
such extensions on an existing system with legacy applications, for
similar reasons that Norm had problems with his compiler and the
billing extensions.

So, maybe one can characterize ACL systems by (1) implicit, mandatory
authority delegation when spawning processes ("ambient authority") and
(2) coarse-grained authority separation across objects.  (And
capability systems can be characterised by the opposite of these.)

Linux is trying to become more flexible.  The clone() interface is
more fine grained than fork(), and the *at() functions (openat,
renameat, etc) allow to use directory handles as first class objects.
This is evolution, not revolution, but these are small, careful steps
towards a finer-grained, less mandatory system.

The interesting question is if one can avoid de-facto ambient
authority in an overall system design, even if it isn't mandatory.  To
give just one challenge: How are you going to name all these objects
floating around?  Will we have to say: "Process 32.6.3.1 (the first
child of the third child of the sixth child of the 32th shell process)
writes to a file object /myconf.txt that is stored on the filesystem
32.5", with no easy way to access that file object?  There is a whole
bunch of crazy---admittedly unsafe---things a power user can do at a
Unix command line shell, and many of them rely on the fact that all
the important objects, namely files and processes, are served on the
platter of a global name space.  That's good for raw productivity, and
it is rather unclear to me how that productivity can be recovered in a
capability system.  I don't mean any particular individual example,
because there is always a solution to any particular problem.  Rather,
I wonder if one can replace the Unix toolset by a comparably usable
toolset for a capability system with pervasive POLA.

Thanks,
Marcus