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

[Jonathan S. Shapiro]

On Sat, 2008-08-30 at 20:32 -0700, Jed Donnelley wrote:
> At 06:54 PM 8/30/2008, Jonathan S. Shapiro wrote:
> >It is very easy in a capability system to transfer O(1) authorities. But
> >once you get much above that you find that you need to introduce some
> >form of namespace for the capabilities being transferred. This is, in
> >essence, a file system.
> 
> Hmmm.  So saying suggests to me that you have a much more restrictive
> notion of what you mean by a "capability system" than I do.  Consider
> the E language for example - or any OO language for that matter.
> There what consists of a "capability" is essentially a pointer
> that can be named as with any other language object.  Such objects
> as parameters occur quite frequently in numbers other than
> 0 or 1.

Jed:

Please re-read what I wrote. I wrote O(1), not "zero or 1". The issue is
that when any larger number of capabilities is transferred, an
organizing (naming) scheme soon becomes necessary so that the two sides
can keep them straight. And somewhere around O(20) capabilities, it
becomes performance prohibitive to construct those organizations on the
fly. As a consequence they cease to be transient, and we find ourselves
looking at something that looks a lot like a name space or directory
space that gets handed to *everyone*.

What I'm saying is that capabilities work very well at O(1), or at
"while namespace" granularity, but dynamic construction of authority
pools (capability or otherwise) doesn't work well in between these two
endpoints.

> In many other systems that I consider capability systems (e.g.
> all the "password" capability systems - Amoeba, NLTSS, Monash,
> etc.) capabilities are just blocks of data and so can appear
> in messages in any number and named in any way convenient.

I agree that in capability systems where data is capabilities (which I
consider to be broken) My O(1) number can probably be extended to O(20).
But the root problem isn't the cost of capability transfer. It is the
cost of *organizing* capabilities to be transferred.

> > > 1.  Communicate the whole principle, or
> > > 2.  Communicate only individual authorities/capabilities.
> >
> >Because of the construction costs that I outline above, I claim that
> >precisely the same issue arises in capability systems.
> 
> And I hope my discussion above clarifies why I disagree with
> that position.

It does not, because you have not addressed the cause of the problem.

> > > I agree that ACLs can be used to implement capability
> > > semantics that will address POLA and Confused Deputy
> > > needs.  What is fundamentally needed is access control
> > > based at the level of individual processes (active objects).
> >
> >This is precisely what Plan 9 did. In plan 9, there is no universal
> >filesystem root. Namespaces can be constructed on a per-process basis,
> >and can be mediated through user-level file systems.
> 
> The difficulty that I believe such systems face is in providing
> effective (convenient, efficient, etc.) communication of
> individual and/or small collections of authorities ("capabilities").

The difficulty I have is that I don't believe this to be terribly
useful. In a modern system, there is a huge space of libraries and so
forth that must be transferred by reference. In reality, programs cannot
be executed using "a few" capabilities.

> >I fully agree. The main pragmatic value of ACLs seems to be dealing with
> >group sharing.
> 
> Hmmm.  To me group sharing is just as easy with capability systems.
> Creating a "group" is as simple as creating a directory.  Just
> share it with the "group".

Yes. I oversimplified. The main pragmatic value of ACLs lies in
surviving the *end* of group sharing. All of the capability-based
mechanisms proposed for this to date are horrendously complicated and
un-engineerable.


shap