[vm][q] what's needed to support multiple, disjoint
Mark S. Miller
markm at caplet.com
Sun Jan 26 07:20:25 UTC 2003
At 09:12 PM 1/25/2003 Saturday, William Cole wrote:
>1.) Provide a proxy forwarder interface between the secure/non-secure
>2.) Encapsulate secure objects with a "Security Object".
>3.) Segregate secure/non-secure code into two separate "environments" or
>Java as a language is easier to secure in many ways than Smalltalk. And for
>securing Java approach 1 or 2 work quite effectively (i.e. 'E'). I would
>rate 1 & 2 as less than desirable for Smalltalk for the simple reason that
>there are too many "Points of Entry" via message sends that have to be
>buttoned up. And the more points of entry you have, the higher the
>probability of comprise.
Short form: I don't think Java was any easier to secure than Smalltalk would
The last Smalltalk I was intimately familiar with was ParcPlace Smalltalk-80
v2.5, so if there are differences between it and Squeak that invalidate the
following, I'd love to hear 'em. Below, I will refer to this old Smalltalk as
The Java and Smalltalk kernels/virtual-machines are both similarly close to
being pure capability machines. They both screw up in the same place --
global/static mutable state.
There is one way that Java is better -- no global name space. In Java, a
fully qualified class name is specific to a ClassLoader. By loading the same
*.class file into two different ClassLoaders, you get two different classes
with two different sets of static (class) variables. Java's supposed
security is built around the idea that a protection domain is a
ClassLoader + all the classes loaded by that loader + all instances of those
classes. Java's "security" applies ACL logic to this unit. At Electric
Communities, we considered doing a Java-based capability system with this as
the supported protection domain, but with normal object references and
messages going both within and between such domains. As I write this, it
strikes me how similar it would have been to Lex's islands. In any case, we
never did it, so the relative benefits and costs compared to
object-granularity protection domains remains speculative.
What we did do is build a new language and virtual machine (Kernel-E) on top
of Java. For this, Java's similarity to a capability system was irrelevant.
For example, we have made a start on rebuilding the Kernel-E virtual machine
in C++ and it has the same structure. Needless to say, Smalltalk would be
fine here. I see no further relevant differences at the virtual machine level.
The real issue we're all wrestling with is the large legacy of libraries. We
knew that the only way E could succeed is if we could somehow inherit a
large amount of library code, and make much of its functionality available
to E *as if* these libraries had been written properly to capability
discipline. We call this process "taming". Taming is the most accident prone
part of creating E, and the part where we're perpetually in greatest danger
of blowing our security. However, it works well enough to keep using, and
is better than any alternative we know except obtaining the funding needed
to burn the diskpacks and start over from scratch.
You can read about taming at http://www.erights.org/elib/legacy/index.html .
In particular, I recommend the section from the security review
instill the proper level of terror about how hard this is to get right.
In any case, oo libraries written in a good modular oo style are often
successfully tame-able. For others, we often went down a rathole trying to
tame them, when we instead should have rewritten them. In any case, assuming
that Smalltalk's libraries are generally written in a better oo style than
are Java's, they should be more easily tame-able.
Except for the Java-ClassLoader opportunity which E makes no use of, I see no
other advantage Java has over Smalltalk as a basis for building a new secure
language and virtual machine.
Text by me above is hereby placed in the public domain
More information about the Squeak-dev