At 06:13 AM 1/26/2003 Sunday, Stephen Pair wrote:

>I think it's important to think in terms of capabilities, not segmenting
>the image and such.

Yes.

>The system really needs to be redesigned from the
>ground up to take capability based security into account.

Yes. It's a pleasure to see this acknowledged.

>There are a
>couple of things that we need before we can actually tackle it
>however...

Many of these things are already provided by the Kernel-E virtual machine 
design. Those that aren't already provided by Kernel-E are probably needed 
by Kernel-E as well. So I hereby officially (whatever the hell that can 
possibly mean) propose the Kernel-E virtual machine design as a starting 
point on this "from the ground up" vm design, to be jointly evolved as we 
realize fundamental features that it should have to meet our respective goals.

Note that I am not proposing either the current JVM-based Kernel-E 
implementation or the nascent C++-based implementation, nor the current E 
syntax nor libraries. I am proposing Kernel-E as a design and as a VM spec, 
to be re-implemented out of the material of the Squeak virtual machine's 
implementation.

This can and should start out as an implementation of Kernel-E in Squeak, 
but this is just a development step that leaves Kernel-E in the same kind of 
second-class status that it currently has on the JVM. Instead, I hope to see 
the Squeak vm interface and the Kernel-E vm interface both supported 
alongside each other and sitting on top of the same object memory, gc, 
method dispatch, and execution mechanisms.

The purpose of preserving the Squeak vm interface is to run those old 
non-capability-based Squeak libraries until we can afford to replace them. 
Until then, I propose we also create a taming mechanism and move it into the 
implementation, to sit "between" the two virtual machines. The main thing 
this means is that a Smalltalk behavior has two method dispatch tables: one 
as seen from Smalltalk, and another as seen from Kernel-E. This avoid the 
"proxy object" overhead.

The result need not be E. E is defined not just by Kernel-E but by a C-like 
surface syntax and by a set of standard sort-of-Java-like libraries, 
sometimes inherited (via taming) from Java. Instead, you can build a 
Squeak-like language on the Kernel-E vm, with a Squeak-like syntax and feel, 
and with Squeak-like libraries, many of which will start out as tamings of 
existing Squeak libraries. Perhaps this is what the "Squeak-E" project 
becomes, so perhaps this is what we should call the resulting language.

This direction is radical and expensive, but I believe something like it is 
approximately the least radical one that works well enough to be worth 
doing. At Electric Communities we painfully went through three different 
attempts to turn the almost-capability-secure Java into a capability-secure 
system. The other approaches (including the island-like one) seemed easier 
but turned out to be harder or impossible.

The main problem on my end with making this proposal is the terribly 
inadequate state of the Kernel-E documentation. If you guys find this 
direction appealing, I will flesh out the docs on an as-needed basis so that 
we can continue to evaluate this proposal.


>we need a good meta object protocol that will enable an object
>to protect direct access to it's state (i.e. #instVarAt:put: and friends
>should be usable only indirectly through some reflection object).

Kernel-E has a "meta.scope()" (Would be "meta scope" in Squeak-E syntax) 
expression that's inspired by, among other things, the Smalltalk 
"thisContext". Like "thisContext", "meta" is a keyword. "meta.scope()" 
evaluates to a map (ie, a Dictionary) mapping in-scope variable names to 
their corresponding Slot objects (reified value-holding variables).

The in-scope variables include all lexically visible variables up to the 
containing object boundary, then the instance variables (the variables used 
freely by the innermost containing object), then the outer variables. It 
contains no more than this in order to allow the garbage collector to gc 
obviously not needed variable values.

There needs to be a corresponding "meta.<something>" expression for 
accessing the Kernel-E AST of any of the lexically enclosing object 
definition expressions. This AST serves a role in Kernel-E like class or 
behavior does in Smalltalk.


>  The
>MOP also needs to enable any object to fully replicate the protocol of
>another object...which would probably require both delegation and the
>ability to provide custome message responders (overriding the normal
>message lookup).

I don't understand this.


>  We also need to re-design the current meta model from
>the ground up (allowing for name spaces, environment, etc).

Yes. Please look at Kernel-E.


>Then, objects could provide façades that offer more restricted
>capabilities and which would prevent any direct access to the façade's
>state (i.e. the underlying object reference).

Trivial in Kernel-E.


>The VM would probably also need some way of enclosing object references
>in some sort of cryptographically secure envelope that would enable only
>the designated recipient to access the object reference.

Kernel-E has nothing like this, and the need has never come up. What do you 
have in mind?


>Once you have these foundations in place, then you could conceivably
>design a system where capabilities are protected by controlling object
>references.  Each "door" that is "unlocked" in the system would expose
>some set of capabilities by opening up access to some set of objects.  

A good image.

>I imagine that using this system, you could even design a processor
>scheduling system that would be resilient to denial of service types of
>attack.

That's where vats should come in. You can't usefully reify resource use at 
the granularity of the individual object, and shared memory multi-threading 
is an unmitigated disaster. You can and should put vats on a resource budget 
of both time and space. See KeyKOS's and EROS's Meters, Schedules, and Space 
Banks for principled ways to do this. It can indeed solve many denial of 
service problems.

Fortunately, this is one of the rare security issues that can be postponed 
without painting yourself into a corner. E currently postpones this.


>I think http://erights.org/ has some good information on this topic.

Thanks!  Hopefully my posts here can help provide a bridge.


----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM