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@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@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