[Squeak-e] Comments on Anthony's "...Shared Smalltalk"

[Mark S. Miller]

Rob, I admit I'm a bit confused by your message. Earlier, you wrote:

At 07:49 PM 1/30/2003 Thursday, Robert Withers wrote:
>Well, it has that burn the diskpacks feel to it, and that's a plus, i believe.

which I applaud. In this message you write:

At 12:30 PM 2/7/2003 Friday, Withers, Robert wrote:
>we should only extend squeak to start supporting security, and keep it 
>backwards compatible.

which is the opposite. In any case, for the kind of security we've been 
talking about, this isn't possible. (For another kind, see "A Coherent 
Retreat" below.) Security leverages both abilities and inabilities. Both 
must be carefully designed. Without the right inabilities, you don't have 
security at all. Once you have the right inabilities (as in my proposal that 
we should specify a capability secure subset of ANSI Smalltalk), then you 
may have security, but you don't yet have a useful system. As you add 
abilities back to such a system, but in a way that preserves the crucial 
inabilities, you make the system more usable without losing its security.

I think that, by doing this, we can eventually build back up to something 
close to the level of functionality of current Squeak. But the result will 
not be compatible. You cannot add inabilities to a system the way you add a 
new package. New inabilities means that some old code must break.

This process -- removing everything that doesn't follow capability 
discipline, followed by adding back in new APIs that provide similar 
functionality in a capability-compatible way -- is a kind of refactoring, 
though a much more violent case then we normally encounter. A great example 
is Lex's ObjectInspector in the Island's work. It moves the reflective 
messages from the objects themselves, where any client of the object could 
invoke them, and puts them instead on ObjectInspector, which can be given 
only to those that should indeed be authorized to break the encapsulation of 
these objects. (The Brand system explained earlier enables the issue of 
"which objects" to be dealt with in a finer-grained fashion, but that's not 
relevant to the points I make here.)

If you think you can get to capability security in an upwards compatible 
way, what are you going to do about #instVarAt:? Or the APIs for opening and 
writing any of the user's files? Do you really want any Squeaklet to be able 
to do that?

A Coherent Retreat

There is another kind of capability security you can achieve with full 
upwards compatibility. It is indeed quite useful, it is the one you've 
already made wonderful progress on, it is where E started and stayed for 
years, it is the way E's largest customer is using it, and it is also the 
kind of security supported by Waterken Software http://www.waterken.com . If 
indeed the Squeak community is not willing to take the steps needed to 
design and build a Squeak-like capability secure *language*, then this may 
indeed be a good place to retreat to. In any case, it's something you need 
to build anyway, it's something you are building anyway, and it may be a 
good place to start.

This alternative is to just implement a cryptographic capability protocol 
for communication between images. (eg, CapTP on VatTP or 
WOMP on VatTP or HTTPS.) (Note: even in this scenario you may wish to 
support multiple vats per image, but this serves no further security 
function. The security is as-if you were just using capabilities between 
images.)

This kind of security is the addition of a crypto protocol library, and can 
indeed be added to an existing system as a package, just as you'd add any 
other package to the system. It contributes no inabilities to an image. All 
of an image is in the user's TCB, and the user's interests are therefore 
vulnerable to all the code he's running in his own image. What it does do is 
allow users to take their own authority, subdivide it into fine grained 
pieces or derive new authority from by abstraction, and share these derived 
authorities with others in order to bring about cooperation without 
vulnerability. One can also bring up servers acting as trusted 
intermediaries, as in the "mint" in the Ode. Indeed, eChat and everything in 
the Ode is perfectly viable at this level of security.

What you give up is language-based security. Nothing above leverages the 
almost-capability nature of Smalltalk. You wouldn't be achieving anything 
that couldn't be achieved equally well by C++ programmers using a CapTP 
library written in C++. You'd have no ability to locally run code you don't 
trust, and therefore no ability to make Squeaklets happen.

So if this is indeed done as a retreat, it would sadden me. I think that a 
Squeak-E *language* would be a wonderful thing. But better retreat than 
total surrender.


>> "Mark S. Miller" <markm at caplet.com> wrote:
>> > (The above argument is also bit of a preview of my upcoming 
>> "What's Wrong 
>> > with Dynamic Scoping?")

>> From: Anthony Hannan [mailto:ajh18 at cornell.edu]
>> I agree dynamic scoping is bad (my "smart" capabilities would have
>> relied on it).  The only tricky thing is how to handle exceptions.

At 12:30 PM 2/7/2003 Friday, Withers, Robert wrote:
>Guys, I don't agree that dynamic scoping is bad, it just may not be secure
>in it's current form.  Colin's recent comments drives this point home.  If
>the environment isn't open from top to bottom to our investigation and
>modification, then it isn't going to be Smalltalk.  This is a critical
>feature to retain.

In the kind of massive refactoring we'd need to get language-based security, 
not only can't we be upwards compatible, we can't necessarily retain all the 
features we'd like. Our likes evolved without constraint of security. Some 
things we like may be incompatible with security. Or it may be years before 
we invent the reconciliation that allows us to revive some form of a feature 
we like without breaking security (as in my explanation of the Safra/Shapiro 
virtually nested virtual machines notion). 

In the meantime, we have to break the feature, not security. If we proceed 
the other way around, we'll never be secure. This means it'll go though a 
phase where it may be Smalltalk-like to many eyes, but where the cognoscenti 
may indeed judge that "it isn't going to be Smalltalk". If you're not 
willing to go through such a phase, don't bite off language-based security.


>Traits, continuations and my eventual sending redirectors are other examples
>where either dynamic scoping or system openness are crucial to allow us the
>facility.

Traits looks very cool, but I don't really understand them yet.

Allow me to correct myself. Traits looks *very* cool!

How do any of these require dynamic scoping or the existing kind of system 
openness (as opposed to the kind shown in Lex's Islands work)?


>  The reason I include both dynamic scoping and system openness, is
>that the openness of Squeak _currently_ depends on dynamic scoping.

In what way? ParcPlace Smalltalk 2.5 and all ancestors I'm aware of going 
back to Smalltalk-76 (but not Smalltalk-72), had extreme system openness 
without any dynamic scoping.


>  We
>shouldn't lose this as we shift towards more security; in fact we should
>only extend squeak to start supporting security, and keep it backwards
>compatible.  

Commented on above.


>We can start this process by looking at providing more vm support for
>evental sending, finishing CapTP, and by migrating Lex's Islands work to
>3.5.

Lex's Islands work defines a new language and core libraries that is in no 
way upwards compatible with existing Squeak. And it cannot, given his goals, 
and what I've been assuming are our goals.


>Thus I think the short-term (couple of months) goal should be
>supporting security level 2 of Mark's original proposal.

I sent out that taxonomy in order to get a sense of how far the group was 
willing to go and at what price. The answer seemed to be, all the way 
(level 4). Since then, I've been posting on the assumption that that's what 
we're going for. Perhaps, now that the costs are clearer, a different level 
of ambition is desired. Well, that's one of the purposes of having a taxonomy.

But all the levels in my earlier taxonomy require language-based security. 
(I failed to include the above "retreat" proposal in my earlier taxonomy.) 
Not even level 1 (Java applet-like: does no harm, but is mostly useless) can 
be achieved upwards compatibly, as Java does not: Applets effectively see a 
different library API than do Java applications. You cannot generally run 
Java applications as applets. If you could, there'd be no security.


> > Your right, I'm giving too much authority to Kernel creators. 
>>  So instead
>> I propose that once a creator "releases" his class he can no longer
>> change it.  If he wants to make revisions he has to create a new
>> subclass.  Others may decide to use his new subclass or not.  They may
>> migrate existing instances to the new class and/or use the 
>> new class for
>> new instances.
>
>I don't like this restriction.  Classes and code should be able to evolve.
>Now if an 'Island' has classes bound into it, those classes shouldn't
>change, unless the right capabilities to change them are held.

And what are the right capabilities?


>I think the argument Mark is making is that there isn't a central authority.
>In fact, there is no third party security sever or third party interface
>respository.  I do think that we could specify the protocols for a base
>library, but that's really what the ANSI spec is about.  There may be some
>library specification additions for supporting security/eventual sends.

Well, I am making that point. But in the context of Anthony's design -- a 
distributed shared heap, in which all replicas of an object are considered 
to be the "same" object -- then, for replicas for which there's no one party 
that everyone else is willing to take as authoritative, such objects must be 
immutable. If you don't like the immutability, then some other assumption 
must give, which is plausible, but leads to a different design.


>> MarkM wrote:
>
>> > Same problem then. I think these can't be automatically 
>> replicated, because 
>> > there is no one authority everyone would mutually trust. At 
>> least I hope there 
>> > won't be. A world in which there's some one authority 
>> everyone is willing to 
>> > make themselves fully vulnerable to is a world ripe for 
>> dictatorship.
>> 
>> Yes, like above I will change this so no one has authority once the
>> pool is "released".  However, I will still allow the creator 
>> to add new
>> classes to a pool.  This is where he could add his new 
>> subclass versions. 
>> Adding to a pool is benign.
>
>Again, I think that with the right capability, these things could be changed
>'locally'.  The issue is that there isn't a global authority.

You're "locally" implies a change of assumptions that probably could be made 
to work, but breaks the uniformity of the distributed heap notion Anthony is 
trying for. It would lead to a different design.



>I am encouraged that although this list is turning out to be on the quiet
>side, there is much interest in what we are considering.  The fact that we
>are doing so in a thoughtful way is to our advantage.   

I've been curious about the sudden quietness myself.


>I will be a little more active this weekend, now that the work week is
>winding down.  I want to implement RemoteHandlers (virtual circuits with
>remote objects) and the objectMap.  
>
>The other dimension, that I have been doing a little work with this past
>week, is cleaning up the EventualReferences.   I am hanging out on the IRC
>channel #squeak-e and will be available there to guide anyone wanting to
>dive into this very intriguing mechanism.  Look at ReferenceContext (the
>eventual reference), and RedirectionManager (the underlying redirection
>mechanism).  If you build a redirection vm, make sure you doit to
>'RedirectionManager enable'.  I will update the SqueakElib package this
>evening.

Cool, looking forward to it!


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

        Cheers,
        --MarkM