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

[Jed Donnelley]

At 08:53 AM 8/30/2008, Jonathan S. Shapiro wrote:
>Since nobody responded to my heretical challenge about confused deputy,
>let me see if I can stir up some more controversy: principal-based
>authority systems are not inherently bad.

Sorry, I'm not following cap-talk quite as actively as I have in the 
past.  Please see my response to that message under separate cover.

>I posit, for the moment, a "modified ACL system" [which I am tempted not
>to define, out of respect for tradition]. There is a first-class object
>that I will call Principal. Operations require both an Object reference
>and a Principal reference, and a predicate is applied to the (Object,
>Principal, Operation) tuple to determine whether the operation is
>permitted.
>
>Note that this can be simulated by capabilities: if a unique ID exists
>for each object, then a Principal can be implemented straightforwardly
>as a hash table of capabilities indexed by Object::id. It follows that
>the problem with ACL systems must somehow lie in the way that
>permissions are aggregated and propagated.

Certainly.  As I noted in my previous message, the implementation 
doesn't matter so much as the semantics - that is the ability to 
possess and communicate individual authorities.

>In my experience, there are three problems with ACL systems:
>
>   1.  The first I have already raised, which is the absence of explicit
>       designation. This is straightforward to repair in the way that
>       I suggested in the previous "Heresy" thread.
>
>   2.  The second is not really an ACL issue, but it is a nearly
>       universal failure of ACL systems: identity is not preserved
>       in the face of distribution. What I really mean here is that
>       NSF is a complete balls-up mistake. This type of thing can
>       be resolved by cryptographic identities, and the Factotum work
>       in Plan 9 is a good example.
>
>   3.  ACLs are not readily subdivisible. That is: it is very difficult
>       to transfer a subset of the authority represented by a Principal.
>       But I claim that this is also true of capability systems.

Sorry, but I don't understand what you mean when you suggest that
"it is very difficult to transfer a subset of authority represented
by a capability system."  Of course with capability systems
(even if implemented using an underlying ACL mechanism), it
is always easy to transfer a subset of the authority - simply
by transferring only the capabilities desired (even if this is
done by changing ACLs).

>It is the third point that I want to focus on, because this is the area
>where we in the capability community complain most heavily about ACL
>systems. On reflection, I want to suggest that this problem is actually
>*worse* in capability systems.
>
>The main source of authority proliferation in ACL systems is through
>propagation name spaces. I argue that the *real* problem in ACL systems
>is not that principal IDs fail. The real problem lies in the face that
>namespace capabilities propagate across fork/exec in such systems by
>default, and in the fact that for the most part access to these
>namespaces cannot be mediated.

I don't agree.  While it may be convenient in the sort of "principle"
based systems to communicate a principle by default when something
a fork/exec is done, the real problem is that there are only two
alternatives:

1.  Communicate the whole principle, or
2.  Communicate only individual authorities/capabilities.

In capability systems (however implemented) it is simply recognized
that there is no particular value in communicating whole principles.
That doing so is awkward and confuses things.  Doing so has the
problem, for example, that an "authority token" in one context
(active object/process) that requires a coupled principle
can end up being meaninglessly communicated without the
needed coupled principle.  Such "half" capabilities can then
suddenly turn in bundles if a principle capability is
communicated.

While I believe I was able to justify a pure ACL-based
capability system where each process (e.g. by network
address) was it's own principle, in my opinion building
a system where principles can be communicated (e.g.
with a single active object/process with multiple
principles) becomes complex and confusing to the point
of absurdity.

>*Given* that namespaces propagate by default, principal id's serve a
>useful purpose: they provide some degree of filtering on the damage. In
>a pure capability model, when a namespace is propagated, no
>corresponding means of filtering is present. In consequence, propagation
>of namespace capabilities is even *more* damaging in capability systems
>than in other systems.

Whether propagated by default or not it seems to me that any
propagation of "namespace capabilities" (principles) is
'damaging'.

> >From a usability perspective, the best mechanism we have come up with
>for bulk propagation and protection of authorities has been the power
>box.

Hmmm.  I thought the best mechanism for the bulk propagation and
protection of authorities was the "directory" (c-list, call it
what you will).  I think of the "power box" mechanism as a
user interface mechanism that allows a user communicating to
a powerful process (e.g. a "shell") to communicate explicit
capabilities to another process (an "application" process)
under control of the user (person) communicating interactively
with the power box process.

>Observe that the protection of the power box derives entirely from
>its ability to act as a filter. The power box itself operates with the
>full authority of its user.
>
>In light of which, I am forced to ask whether filtering isn't the key to
>the whole thing.

The "filtering" of a power box that you refer to happens in
a rather specialized situation - where an application program
needs to ask for specific authorities to do it's needed job.

Another common case is that in which one program wants to
communicate just a needed set of authorities to another
with the understanding that no later adjustments will be
needed.  The usual OO interface.  In that case no "power
box" mechanism is needed.  Also we see in that case that
what is fundamentally needed is the ability for both
communicating entities to have separate authorities and
to be able to communicate them between one another.  This
is the "capability" interface semantics - regardless of
whether it is implemented with protected pointers, so-called
"password" capabilities, ACL-based capabilities or whatever.

>If that is so, then Plan 9 may have gotten matters
>largely right.
>
>Now I concede that Plan 9 accomplished this because there are
>capabilities (at least conceptually) at the bottom, and because
>namespace propagation is explicit. The reason this matters, to my mind,
>is that the Plan 9 approach preserves an API that is largely capable of
>preserving existing applications.
>
>Reactions? Thoughts? Rotten tomatoes?

I'm sorry but I don't know (or remember) enough about the
access control mechanisms in Plan 9 to comment meaningfully.

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).
ACL systems typically don't provide such a fine level of
control, partly because the mechanisms for delegating
authorities typically become difficult as they devolve
to communicating "capabilities" which most ACL advocates
see as anathema since it would suggest loss of control
over access.  Most ACL systems think of the "principles"
as users/people.  At that level I believe ACL systems
will continue to be inadequate for POLA and/or Confused
Deputy needs.

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