A note on rationale
Tue, 2 Nov 1999 11:12:36 -0500
I want to explain briefly why I am pushing so hard on capability notions at
the moment. As you all know, I've been working on capability systems for a
long time, and I basically believe that they are a good mechanism; one I
would not wish to give up.
The current testing is motivated by a challenging question that was posed
by Paul Karger. The problem is this:
Assume that the user is not competent to judge the safety of the tools they
use, and that indeed some of those tools are in some way compromised. This
is the necessary presumption if we are to run commercial off-the-shelf
software. How can we grant those tools the capabilities they need to have
in order to operate without having the capabilities leak, and without
demanding that the users exercise a greater degree of paranoia than their
degree of knowledge can sustain?
I don't see how to do this in a pure capability system. I'm not advocating
ACL's as an alternative, but there are some kinds of "tagged object" or
"tagged compartment" strategies that don't suffer from the same problems
that ACLs do. The fundamental problem with ACLs is inadequate protection
-- one can never really be sure of the user's identity, and if
communication channels are permitted at all the programs can proxy. This
is not true of (e.g.) compartments in an MLS system -- the compartment id's
are quite unforgeable, and the relationships between them explicitly
controlled. While a failure of authentication may lead to compromise of
compartments, the scope of potential impact of that compromise can be
So I'm not really interested in ACL systems per se. I may arrive at a
place where I want all capability invocation to occur within the scope of
some session authentication for reasons of traceability.
Jonathan S. Shapiro, Ph. D.
Research Staff Member
IBM T.J. Watson Research Center
Phone: +1 914 784 7085 (Tieline: 863)
Fax: +1 914 784 7595