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

Tyler Close tclose@oilspace.com
Sat, 27 Jan 2001 16:14:51 -0000

I (Tyler) wrote:
> 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?


> I can think of several reasons why this would be the case.

I neglected to mention the most important reasons.

An ACL system has a fixed interface. This interface is also not very
rich. You have the ability to add and remove principles from the
access lists, but that's about it. Writing interesting collaborative
software is about creating much more interesting authority flows. One
of the simpler ones is the "once-only" authority. Carol is authorized
to use Bob once, but after that use the authority goes away. ACL
system's don't provide for such notification and action upon use of an
authority. Carol is on the list, and stays on the list until removed.
Carol can use Bob as much as she likes while she has the CPU. More
interesting scenarios are when the ability to use one right is
contingent upon giving up others. ACL system's don't try to provide
for these authority dependency graphs. This functionality is *very*
important. It's pretty much all of what I do every day as a designer
of capability based software. I would feel very lost and impotent if
restricted to working with an ACL. From this perspective, you could
think of a capability system as a "Wagner ACL" with a programmable
interface to the ACL. This "Wagner ACL" is getting very complicated.
Much of the application capability code that I write is solely
concerned with the flow and dependencies of rights. This "Wagner ACL"
would have to have the ability to completely duplicate this logic
within the "central database".

Depending on the details of how a "Wagner ACL" was designed, it might
also prevent me from working with objects that are broken from a
security point of view. A particular object may encapsulate more
authority than it should. The principal requires the ability to access
this object, but must be restricted to using it in certain ways. In a
capability system, this is trivially accomplished using a protection
proxy object. I don't know how you would do the same in an ACL system
that prevented the principal from causing invocations of the protected
object. Consider for instance, Java's stack introspection
implementation of an ACL.