At 09:12 PM 1/25/2003 Saturday, William Cole wrote:
>1.) Provide a proxy forwarder interface between the secure/non-secure 
>subsystem boundaries.
>
>2.) Encapsulate secure objects with a "Security Object".
>
>3.) Segregate secure/non-secure code into two separate "environments" or 
>"spaces".
>
>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 
be.


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 
"Smalltalk".

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 
http://www.combex.com/papers/darpa-review/security-review.html#taming to 
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

        Cheers,
        --MarkM