[E-Lang] E FAQ

[Mark S. Miller]

[Forwarded with permission.  --MarkM]

At 04:34 PM 10/11/2001 Thursday, David Wagner wrote:
>Thanks.  I enjoyed reading that article.
>
>However, I had a hard time following one statement there:
>: Principal-oriented 
>: architectures generally assume that when A invokes B, that B's actions 
>: honestly represent A's intentions.
>
>To me, Java stack introspection seems explicitly designed with powerful
>features for addressing exactly this sort of issue.

Well, features, but I don't know if I'd say "powerful".


>If A invokes B, by
>default B's actions gets only the privileges common to both A and B; thus,
>by default, we assume that B's actions do *not* represent A's intentions
>(at least, B doesn't get any extra permissions as a result of A's request).
>If B tries to cause trouble and do something B wouldn't have wanted, B
>can't use the fact that A called B to do anything B wouldn't already be
>able to do on its own.

How does A provide some of its authority to B, such that B can exercise it 
other than while called by A?  For example, many Java subsystems, like 
Swing, operate on an event-loop basis, but when an invocation is turned into 
a request record of some sort on an event loop, it looses the (implicit, 
unreified, non-first-class) representation of the authority of the invoker.

One could imagine a variant in which this and a thousand other problems were 
fixed, much as you were exploring ways to fix Unix or ACL systems.  Once one 
is done, has one captured the essence of the model -- the model struggling 
to get out, or has one created a different model?

I don't know, but that's one of the reasons I encouraged Scott Smith and 
Chris Skalka to create a simple secure language around a security model 
abstracted from Java's security.  The clarity that would result would allow 
us to understand both the essential flaws, and the essential virtues, if 
any, of this model.

Now, having been clear on the extent of my confusion and uncertainty about 
Java's security model, here's why I say that it's Principal-oriented.

An atomic entity, from a security perspective in this model, is the set of 
classes loaded by a particular ClassLoader, and all the instances of these 
classes.  The SecurityManager allows or disallows an operation based on the 
ClassLoader associated with the invoker (or the invoker's invoker, etc, as 
the SecurityManager can look up the stack), and the permissions granted to the ClassLoader.

1) The permissions are granted to a ClassLoader statically, in a properties 
file, as an expression of an external security policy.  As we've discussed 
on the list many times, designation and confinement issues aside, an ACL 
system and a Capability system can each represent approximately the same 
static access matrix.  Where they fundamentally differ is in how they manage 
the permissions to cause changes to the matrix.  Since, AFAIK, entities 
within the system have no ability to alter the matrix, in that sense, it's 
fundamentally weaker than either an ACL or capability system.

2) But it's ACL-like in that authority applied to an operation is according 
the authority the invoker has, not the authority the invoker applies, and 
that this source of authority is unreified, and therefore undelegatable.

3) Regarding the delegation issue ignored above, the properties file 
designates authorities by naming them, in some static namespace that must be 
global to a jvm.  Whether this is fundamental to ACLs, it seems to be 
universal to ACLs in practice (except for the Udanax Gold club system), as 
opposed to Capabilities use of opaque, dynamically-generated, first-class 
designators. File names vs object references.


Java and SPKI are similar on #2 and #3, and we have said that SPKI is 
ACL-like in that way, and that these attributed make SPKI weaker.  However, 
altogether, we consider SPKI to be a capabilities-fellow-traveller because 
it does #1 using approximately capability logic (except for the 
confinement-enabling Alice-Bob requirement).



>The real issue seems to be least privilege.  

That is certainly also a real issue, but so are the above issues.


>Many Java apps do not
>run with least privilege.  However, the possibility is there in the
>architecture to do much better in this regard.  If apps normally ran
>with all privileges disabled, and bracketed only those areas where they
>need privilege P with enablePrivilege(P); ...; disablePrivileged(P),
>this would be a big step towards least privilege, wouldn't it?

It would certainly be an improvement.  But how fine grained can P be?  Can 
it be as fine grained as a capability (even ignoring the difference between 
objects and ClassLoader-based aggregate entities)?  See below.


>A bigger difference seems to be that E-style capabilities systems are
>intended to (1) make it easier to get least privilege ("it comes for
>free"), 

This is certainly an enormous difference between capabilities (not just E) 
and ACLs -- "A capability combines designation and authority."  You'll 
recall, this is the punch line of the confused deputy.  So long as these are 
separate, deputies will be confusable.


>and (2) potentially provide finer- grained privileges ("each
>object ref is a privilege").  

Yes, but object vs some large aggregate isn't the most important issue.  The 
biggest granularity issue is whether Principals and Resources can be named 
in a static namespace, or whether the security policy can separately 
designate dynamically created instances.


>Thus, E seems to be intended to make it
>easier to do the right thing.

That's certainly true, and I would claim, more so than any system for 
expressing secure computation I know of.  I think it could also be an 
unparalleled teaching language for security and distributed security concepts.


>I'd love to hear whether you would agree with this characterization,
>or whether I'm missing something important.

If you feel this still leaves open issues that bears discussion (especially 
given my ignorance of the particulars of the Java 2 security model), you may 
want to continue on e-lang.  If so, please feel free to forward our 
correspondence.

I hope this helps clarify things.


        Cheers,
        --MarkM