[E-Lang] Java 2 "Security" (was: Re: WelcomeChrisSkalkaandScottSmith of Johns Hopkins)

Tyler Close tclose@oilspace.com
Sat, 27 Jan 2001 12:58:44 -0000


David Wagner wrote:
> But what's of much more interest to me than semantics is a technical
> question: What's the matter with designs that combine ACL's and
> delegation?  For instance, what's broken about my proposal?

Your proposal, as I understand it, is to invert the capability model,
so that all access authorities are held in a central database, as
opposed to being held by the subjects. For example, in a capability
system Alice grants Carol access to Bob by passing Carol a copy of her
capability for Bob. In a "Wagner" system, Alice grants Carol access to
Bob by invoking the system "delegate()" method. Presumably something
like:

	delegate(alice_id, carol_id, bob_id);

Although not stated, I assume that your design also requires that all
accesses of Bob must be preceded by some sort of system "authorize()"
method call, like:

	authorize(carol_id, bob_id);

This authorize() invocation would have to be part of the runtime, such
that is would be impossible for Carol to access Bob without invoking
authorize().

If such a system were implemented, it is easy to see how the "central
database" could be seen as a highly flexible ACL. Based on Jonathan's
responses to your proposal, I am guessing that this degree of
flexibility in an ACL system is not something which has ever been
proposed. I can think of several reasons why this would be the case.

In the example, I used Bob as the object that requires access control.
Bob could be anything, and in general, is anything. A typical program
contains a very large number of objects, each of which encapsulates a
different authority. For example, Bill Frantz's first rough cut at a
mail application sensibly put each email message in a different
object. A finished mail application would contain many more objects of
many different types. Running on a "Wagner ACL" system, this mail
application would result in a very large central database. Every time
one of these objects was accessed, this large central database would
have to be queried. Every time one of these objects passed a
capability to another object, the large central database would have to
be updated. It should be clear that this design is infeasible. In
contrast, it should also be clear that the capability design of "the
pointer is the authority" maps very well onto the application and is
highly efficient.

The "Wagner ACL" system ignores the issue of deciding which objects
require that accesses be preceded by a authorize() system call. Making
this decision is non-trivial. That this decision exists and requires a
choice to be made prior to the application being deployed, necessarily
means that the deployed application will either not offer the desired
protections (such as your Unix filesystem example), or contain far too
many protections, making the system unusable. This trade-off does not
exist in a capability application. Authority can be refined and
expanded by the passing around of pointers as the application is being
used, according to the user's wishes. A "Wagner ACL" system puts the
"principle of least authority" at odds with application usability and
efficiency. In a capability system, these forces positively reinforce
each other.

The "Wagner ACL" system is also highly complex. In a capability
system, the pointer to an object is the authority to use that object.
Designation and authorization are held in one compact unit that is
easily passed around. A "Wagner ACL" system divides this compact unit
into several different entries. A "Wagner ACL" system must maintain a
mapping of identifier to the identified object, a mapping of
principals to the identifiers they are authorized to use and a set of
the objects that require authenticated access. The "Wagner ACL" system
has no particular reason for wanting to be so complex, it just is.

It is unclear to me how a "Wagner ACL" system would support
distributed computing. I can only assume that it would require
including a signed authorization certificate with each invocation.
This certificate would then have to be verified against the invocation
by the object's host computer. How these certificates are meant to be
generated and kept is unclear. It seems very likely that this task
would be far more complicated than the application itself.

If you think of the computer's heap and stack as being a database, the
delegate() method being a normal pointer copy operation, and the
authorize() method as being a pointer dereference operation, then a
capability system can be seen as a highly efficient and flexible
implementation of a "Wagner ACL" system, and a "Wagner ACL" system as
a highly inefficient partial model of a capability system. It seems
strange to want to construct an inefficient partial model of a system
in order to present an interface that is similar to that of a system
that is formally known to be broken.

Tyler