[E-Lang] Java 2 "Security" (was: Re: Welcome Chris Skalka and Scott
Smith of Johns Hopkins)
Mark S. Miller
Mon, 01 Jan 2001 12:11:59 -0800
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
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
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?