[E-Lang] Java 2 "Security" (was: Re: Welcome Chris Skalka and Scott Smith of Johns Hopkins)

[Mark S. Miller]

At 10:51 PM Saturday 12/23/00, Scott Smith wrote:
>I like capabailities a lot myself due to my actor background.  But, I
>don't (yet) consider them "better" necessarily than the other security
>models such as Java's.  One thing I would like to do sometime is get a
>reading of what people here think of the Java 2 model.

Since I think most people here already know what I think of it, I'll mostly 
hold back until some other people jump in.  But I can't resist a few 
historical comments.

To me Java 2 doesn't have one security model, but many, all mushed together. 
 The core language design and the verifier are great starts on what could 
have been a decent capability language, but those in charge of those in 
charge of making Java into a secure language (Arthur van Hoff) proceeded in 
purposeful ignorance of this fact.  (As a result, those in charge of Java 
security at the time (Chuck McMannis) proceeded in reluctant ignorance of 
this fact, and eventually resigned.)

Sun's CTO at the time, Eric Schmidt, understood that the real reason for the 
Security Manager architecture was time to market: with the Security Manager, 
Javasoft could continue to pull teeth until Applets could no longer do 
anything dangerous.  Schmidt understood that the price of pulling teeth 
without first having a real security architecture was that, by the time 
Applets were safe, they might also be useless.  However, this price was 
considered worth paying to hit the market window they were going for.

Java was in fact released in time for Netscape to announce that it would be 
bundled with the browser, and for Netscape to rename "LiveScript" to 
"JavaScript", all shortly before the Netscape IPO.  The combined Java & 
Netscape hype was stratospheric, Java became a permanent part of the 
landscape, and Applets turned out to be almost useless after all.  However, 
by the time anyone noticed that last fact, the Java momentum was 
unstoppable.  Given what happened, I reluctantly admit Schmidt made the 
right call for the right reason.

Arthur van Hoff and Schmidt eventually resigned, but by then Java was 
already committed to the Security Manager + Stack Introspection 
architecture.  This architecture is fundamentally "Principal" oriented, with 
ClassLoader identity serving to identify the Principal.  Principal-oriented 
architectures generally assume that when A invokes B, that B's actions 
honestly represent A's intentions.

E's ancestor, "Original-E", done at Electric Communities, showed how to turn 
Java into a capability-secure and capability-oriented language, as well as a 
capability-oriented distributed language, all with minimal disruption to 
existing Java programmers, but, for the above reasons, without maintaining 
upwards compatibility.  Despite repeated efforts, Electric Communities found 
only deaf ears at Javasoft.  To accept Original-E would be to admit that 
their previous direction was a mistake, which they understandably could not do.

Li Gong eventually took over the Java security effort, and designed the Java 
2 architecture.  Based on his publications, Gong actually understands a good 
deal about capabilities, and is clearly a very smart person.  However, by 
this point Gong was completely constrained to evolving Java's security in 
only upward compatible directions, and to only put a happy face on the 
rationale for the result.  Security is about preventing things from 
happening.  You can't normally fix a broken security architecture without 
preventing some things that weren't previously prevented, and to do so is to 
break upwards compatibility.  Gong choose not to do so, and politically, 
this is probably the only choice he could have made.

So, starting with a Principal-oriented architecture, he dug this hole deeper 
and build a full fledged ACL system.  Publicly, Sun has only presented this 
as the one right thing, as opposed to an attempt to rescue a kludge created 
in a panic.  Despite the history, the resulting system may or may not 
actually be good.  We still need to argue any case on its merits.  But an 
historical perspective can provide some orientation.


>To me it
>certainly provides something, and what it provides is not subsumed by
>capabilities, and so it seems interesting. In terms of the low-level
>information flow, capability flow is a flow of access rights through the
>store, and stack inspection can be represented as a flow of access
>rights down the call stack.  These are very different dimensions.  But,
>I don't claim much of an understanding beyond that.

I would be fascinated to see what it provides that is not subsumed by 
capabilities.  I think we all would.

Regarding "stack" vs "store", as Hewitt teaches (something like "Control 
Flow Seen as Patterns of Passing Messages" in the early 70s.), call, return, 
and all other control transfers can all just be seen as message passing 
operations.  There's nothing magic about the stack.  Most others have 
learned this in turn from the Continuation Passing Style transformation that 
Scheme got from Actors.  As Hewitt explains, a message pass is just a "goto 
with parameters".  Actors deal with the flow of authority through all 
in-model causal pathways, ie, all message passes, whereas Java 2 treats the 
stack as a special category.  So who subsumes whom?


        Cheers,
        --MarkM