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

[Jonathan S. Shapiro]

On Sat, 2008-09-13 at 06:45 +0100, David-Sarah Hopwood wrote:
> Jonathan S. Shapiro wrote:
> > Arrggh. Let me try this again.
> > 
> > There exists a sharing problem that ACLs uniquely solve, and that
> > appears to *require* the de facto separation of designation and
> > authority. It is possible to solve this problem on top of a pure
> > capability substrate, but only by implementing a filter whose net effect
> > is to simulate the behavior of ACLs or something very close to them.
> > 
> > Problem:
> > 
> > Alice, Bob, Henry, Elmo, Oscar, and so forth are involved in a task
> > that requires that all of them manipulate and modify some object
> > graph. By "manipulate and modify", I do not mean merely that they
> > modify the leaves of the graph. I mean also that they modify the
> > structure of the graph itself. It is required that the parties be
> > able to have different access rights on different subgraphs.
> [...]
> > So far as I can tell, the only workable method for solving this problem
> > is mediation of all accesses to the graph in a per-client-user fashion.
> > While this can be implemented by user-mode code on top of a capability
> > substrate, it appears to me that this emulation constitutes, for all
> > practical purposes, an access control list.
> 
> No, it doesn't. Differences between a capability system with some
> responsibility-tracking protocol such as Horton, and an ACL system:

I am not discussing a horton-like protocol. No transitively constructed
membranes are envisioned here.

>  - in the capability system, communicating a capability automatically
>    also delegates the permission to use it (this can be with or without
>    responsibility tracking, so that the authority derived from the
>    capability by its recipient can be independently revoked, at the
>    option of the delegator).

Yes, and the conventional open() call communicates a capability in
exactly this way. This behavior is identical.

>    In the ACL system, you have to communicate a string filename, and
>    then also convince an administrator to edit an ACL in order to make
>    the filename usable by its recipient. The administrator acts as a
>    bottleneck and single-point-of-failure, and has excess authority.
>    Furthermore, this additional ACL-editing overhead makes it totally
>    impractical to have fine-grained protection domains separating
>    processes acting on behalf of a single user.

This is not a property of ACL systems. It is a property of *any*
filtering system that requires administration.

>  - the capability system is less vulnerable to confused deputy
>    attacks. The ACL system requires communicating file designators
>    from a client to a deputy as strings, and then access to the
>    corresponding file is controlled according to the ACL entries
>    for the deputy. But using the deputy's permissions is simply
>    incorrect and insecure in this situation; it should be the client's
>    permissions that are used.

This assumes that the deputy operates with permissions distinct from the
requestor, which is not how a filter behaves.