A note on rationale shapj@us.ibm.com
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 understood.

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
Email: shapj@us.ibm.com
Phone: +1 914 784 7085 (Tieline: 863)
Fax: +1 914 784 7595