Greetings All;

Couldn't resist the urge to jump in on the discussion here.

I don't want to go into the complexities of VM design, but rather provide 
an image-level perspective on the problem.

Several of the security regimes for object systems boil down to three basic 
approaches:

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.

And with Smalltalk once you compromise the system, its all over.  There's 
no way to put the toothpaste back in the tube.

This points to the idea that maybe 3 would be the best approach, as it 
minimizes the contact between secure/non-secure code.  The downside though 
is that a bullet-proof implementation of secured spaces has you recreating 
Object Memory, then which begs the issue "why not just use two images?".

The toughest problem I'm encountering with trying to secure Squeak is this: 
Its not enough to just secure the class hierarchy, but securing *all* the 
shared globals that make up the image environment.

For instance, you can secure the 1900 + classes of Squeak using approach 1 
& 2.  But you then also have to secure:

- 33 Named Globals
- 19 of those 33 globals are Dictionaries of symbol->object 
associations.  Several of these Dictionaries are dynamic, the size 
breathing with use.
- The remaining 16 Globals are instances of complex objects 
(ProcessScheduler, PasteUpMorph, etc.).
- Oh yes, there are also 17 Class Pool Dictionaries (symbol->objects) 
shared across 106 classes.
- Not to forget over 300 classes that declare one or more class variables.

The bottom line is that there are roughly 2-3000 instances of named 
variables that have to be secured (in addition to the class 
hierarchy).  The scalability of encapsulation/proxy approach breaks down at 
this level - especially when considering the dynamic quantity of these 
objects at any given time.  This is why a partitioned approach is necessary 
to protect these "shared" instances.

I feel that a hybrid design incorporating all of the above approaches is 
what's needed to achieve runtime security with Squeak/Croquet.  After 
prototyping security regimes for the last 3 months, the hybrid approach is 
showing most promise.

Just my $.02.

Regards;

Bill Cole