[Squeak-e] Comments on Anthony's "...Shared Smalltalk"
Mark S. Miller
markm at caplet.com
Sat Feb 8 11:02:50 CET 2003
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
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
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
>> "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
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.
>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
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
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
>> 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
Cool, looking forward to it!
Text by me above is hereby placed in the public domain
More information about the Squeak-e