[E-Lang] Merits of ACLs

Jonathan S. Shapiro shap@cs.jhu.edu
Fri, 26 Jan 2001 21:04:14 -0500


I'm really tired of the whole ACL discussion, so I'm joining it.
Comments about the self-evident futility of this approach will be
forwarded to /dev/null.

First, I want to point out that ACLs are fatally flawed only if they are
taken as the sole protection mechanism of the system. This has been
formally shown [Harrison, Ruzzo, Ullman '74]. In contrast, capabilities
not only have decidable (and enforceable) safety, but are also able to
enforce confinement, which is a crucial security building block [Shapiro
'00].

While I agree with MarkM that proxying+conspirators makes nonsense of
policies like "fred cannot access X", it is NOT true that the ACL model
precludes delegation. There is a hidden assumption being made by MarkM,
which is that the "own" right cannot be subdivided. Nothing in the ACL
model precludes introducing a "grant" right separate from the "own"
right. Nothing in the ACL model precludes making the grant right itself
grantable. In such an ACL system, delegation is perfectly feasible. It
may (regrettably) be a rather wider delegation than we want, but it is
feasible. We can even imagine making the "own" right itself delegatable
within the model. Finally, note that ACL delegation is delegation to a
PROCESS, and not to a USER!!!

The problem with ACLs, ***with respect to this issue***, is not a
problem with the model. It is a universal problem with all existing
implementations: the "process as subject" idea is universally replaced
in practice with "user as subject". At that point, delegation becomes
far too broad. The reason for this substitution is that the need to
continually update the access table as processes come and go is
prohibitive if the database of access relationships is attached to the
objects. Many of the objects will prove to be disk based, and it is
simply infeasible to update them in a timely way. For this reason, a
simplifying equivalence class (processes/users) is commonly introduced.
Unfortunately, this equivalence class completely defeats any semblance
of security.

On the other hand, narrow delegation is not assured by capability
systems in general either. The reason that narrow delegation works
actually stands *outside* the capability model. However, the critical
mechanism has only been shown (to date) to be feasible in capability
systems, so it may be that capability systems are a necessary enabler.

It is possible to perform a narrow delegation in a capability system
exactly when the (a) the receiving process is trusted or sandboxed and
(b) the person running the receiving process cannot arbitrarily crack it
open and extract its capabilities. The latter constraint is achievable
in capability systems, but it is not guaranteed that all capability
systems will enforce it. Both EROS and E satisfy constraint (b) because
of the design of their respective runtime systems. We could easily
imagine building other runtimes that are capability runtimes that would
not enforce this property. If we did so, we could conceivably make
delegation in a capability system every bit as bad (i.e. just as
promiscuous) as it is in a conventional ACL implementation.

That being said, I also want to point out that ACLs may nonetheless be
useful if we can step away from the idea that ACL "identity" has to be
understood as user identity. In fact, this was NEVER part of the
definition of an ACL system. The Lampson paper on Protection, which is
probably the definitive source, considers only interactions between
subjects and objects. Subjects, as defined in the Lampson paper, are NOT
users! They are processes!

Now for reasons of implementation, actually using processes as subjects
appears to be prohibitively costly. However, there are other equivalence
classes we might contemplate (i.e. other than the equivalance class
defined by processes/users) that are useful and enforceable. One example
is processes/security-class.

ACLs are not *necessary* to enforce multilevel security. It has been
demonstrated by KeySAFE that such enforcement can be accomplished with a
purely capability-based solution. However, it is worth noting that
KeySAFE is obliged to take a relatively conservative view of what
operations are permissable across compartments, and that KeySAFE must be
conservative precisely because it cannot rely on the runtime to execute
fine-grain protection checks that honor the compartment boundaries. If
objects and processes were both tagged by unalterable integers, and if
capabilities could be efficiently validated at runtime on the basis of
these tags, it would be possible to allow a greater degree of safe
sharing across the compartment boundaries. Formally, this sharing can be
expressed purely in capability terms. Practically, the KeySAFE runtime
has insufficient semantic understanding of the internals of the objects
it oversees to successfully expose the full degree of possible safe
sharing without additional runtime support.

The tag checking I am describing here can be viewed as a form of ACL
check (though it can also be used in other ways). Note that in this
paper design the tag check is performed only *after* we have
demonstrated that the capability exists. Capabilities, in this scenario,
remain necessary but are no longer sufficient.

So: I remain unconvinced that ACLs are an adequate security foundation,
but I can identify cases in operating systems where they provide a
useful orthogonal slice of the protection problem when combined with
capabilities. So far, all of the useful slices I have come up with can
ultimately be traced to the inability of the operating system to know
anything about the behavior, types, and type safety of the programs that
the operating system manages.

Regards,


Jonathan