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

[David-Sarah Hopwood]

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:

 - 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).

   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.

   (Technically, an ACL system doesn't *necessarily* have to require
   ACLs to be edited only by an all-powerful administrator. But if
   you add ACL-editing permissions and the ability to delegate
   permissions without the intervention of an administrator, then
   you have something much more complicated than typical current ACL
   systems. Not to mention that by allowing "uncontrolled" delegation,
   you have then lost the property that is the main *perceived*
   advantage of ACLs to their proponents, and so you might as well
   convince people to use capabilities instead.)

 - 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 difference arises precisely because the capability solution
   does *not* require separation of designation and authority --
   de facto or otherwise.

-- 
David-Sarah Hopwood