[cap-talk] More Heresy: ACLs not inherently bad
david.hopwood at industrial-designers.co.uk
Sat Sep 13 00:45:17 CDT 2008
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.
> 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.
More information about the cap-talk