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
This is a response to some comments about the importance of openness to Smalltalk.
One of the reasons I have not spent more time working on squeak and porting older Smalltalk libraries and tools to Squeak is a confusion about openness and malleability.
Openness:
One of the most wonderful things about a Smalltalk environment is that it is open to inspection, modification, and extension by the developer. This might be the single most important thing about Smalltalk.
But it is *not* at odds with security. What is at odds with security is confounding open-to-the-developer and open-to-any-program-that-happens-to-be-nearby. I would like a Smalltalk system that is open to *me* when it is running on my machine, but in which the programs are not exposed to *each other*. (Indeed systems that try to prevent me from seeing or manipulating things on *my* machine make me very angry! :-)
As MarkM says, getting back to the sense of *the developer* being able to change anything while still preserving capability security could be challenging. But it's a lot easier to get to a place where programs must follow rules with each other, but development tools can get the access they need easily. The general pattern is to replace primitives for getting inappropriate access (e.g., instVarAt) with "closely-held" capabilities: capabilities that are available only to a few programs, which ensure that their use does not violate capability discipline or system integrity.
Let's look at instVarAt: for example. It is primarily there to support meta-level tools like inspecting and debugging. These are almost always tools for developers, not programs. Replace instVarAt primitives with a primitive capability that is closely held by the development tools. The developer's tools then use that capability to look inside any object. Normal programs don't have access to the capability, and so they cannot violate arbitrary object encapsulation. The developer can decide to make a new service that has that capability (e.g., an object serializer for rewriting the Smalltalk image in a different format), but again that doesn't mean the authority is available to the Web server.
Malleability:
Another important facet of Smalltalk's openness is malleability, the fact that a programmer can change anything in the environment. Too often, people confuse this with increasing flexibility in arbitrary dimensions, and removing all barriers and modularity. As a result, it often seems at odds with security. First, I'll give some examples of what I consider bogus malleability in Smalltalk; the basic theme is that Juntas are a symptom, not a solution.
- When I'm refactoring the Browser, I don't want the browser I'm currently using to break. I want to create a new version of the Browser, then try it.
- I might want to (and have!) develop an entirely new user-interface framework, possibly starting from the current one, without breaking my development environment as I go.
- At a non-gui level, I've changed the way that numbers decide on coercions, without breaking the system.
Doing that as Juntas just seems pointless and silly; I should be able to produce a new system without breaking the old version. I want complete control, without having my entire environment feel like it is made of mud because it keeps changing out from under me (and yes, I'm exaggerating a little for effect).
I guess my point here is that one can have a system that is entirely malleable to the developer, with the ability to add structured hooks (closely held) to apply that malleability to new tools or techniques, without having arbitrary malleability be a common element in the programming environment.
So the final claim is that Squeak-E could have the familiarity with Smalltalk, with the differences only showing up for people that "open up the hood", but those people will just open the hood in a slightly different but still easy to understand place, and have all the power they could want. This seems like a useful intermediate target (in the spectrum of security targets) that would also be comfortable to the Smalltalk community.
Comments?
Mark S. Miller squeak-e@lists.squeakfoundation.org said:
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.
I agree that this is the only feasible way. What I've constantly been thinking is that you could ease the transition somewhat by providing 'unsafe Squeak' below Squeak-E in order to have all the bells'n'whistles, not unlike the Java/E relation. However, we could be *way* faster in a situation where everything that *can* run in Squeak-E will actually run in Squeak-E because it is 'merely' a matter of refactoring, not rewriting (and we've got the better tools).
On a side note, I've prepared a version of Squeak that I might be able to redistribute under an open source license (no traces of any Apple fonts in the image ;-)). In order to attract the widest audience, it might be an idea to work on that particular version (which I've dubbed 'CleanSqueak' because the license is cleaned up and my forceful replacement of all original fonts with Helvetica gives quite a clean look ;-))
I'll answer in terms of the 'Draft Consensus Plan' I just posted. Hence the change of title.
At 01:45 PM 2/8/2003 Saturday, cg@cdegroot.com wrote:
[...] What I've constantly been thinking is that you could ease the transition somewhat by providing 'unsafe Squeak' below Squeak-E in order to have all the bells'n'whistles, not unlike the Java/E relation.
Is 'unsafe Squeak' == current Squeak? If so, then this is in line with the Draft Consensus Plan.
However, we could be *way* faster in a situation where everything that *can* run in Squeak-E will actually run in Squeak-E because it is 'merely' a matter of refactoring, not rewriting (and we've got the better tools).
What kind of "faster" did you have in mind? Development time or runtime?
For runtime, I don't think it should make much difference either way.
For development time, some things will be faster to tame, others will be faster to refactor/port. Of course, for the long term, you'd rather refactor/port, so it's good to err on that side.
On a side note, I've prepared a version of Squeak that I might be able to redistribute under an open source license (no traces of any Apple fonts in the image ;-)). In order to attract the widest audience, it might be an idea to work on that particular version (which I've dubbed 'CleanSqueak' because the license is cleaned up and my forceful replacement of all original fonts with Helvetica gives quite a clean look ;-))
Cool! What are your license constraints. I hope you chose a Mozilla compatible license (most anything other than GPL). My preference is MIT X.
---------------------------------------- Text by me above is hereby placed in the public domain
Cheers, --MarkM
Mark S. Miller squeak-e@lists.squeakfoundation.org said:
Is 'unsafe Squeak' == current Squeak? If so, then this is in line with the Draft Consensus Plan.
Yup. I'll snip all the agreements furtherdown, b/c it seems we're in 100% agreement here (I promoted your post to the Front Page of the Swiki :-)).
For development time, some things will be faster to tame, others will be faster to refactor/port. Of course, for the long term, you'd rather refactor/port, so it's good to err on that side.
I was comparing development speed of Java/E vs. Squeak/SqueakE. Just wanted to mention that we could be quite comfortable with having mostly everything in Squeak at the beginning, because it will be relatively easy to move Squeak stuff to SqueakE, as compared to moving Java stuff to E (duh).
Cool! What are your license constraints. I hope you chose a Mozilla compatible license (most anything other than GPL). My preference is MIT X.
Well, the SqueakL says that you may re-release Squeak under a license that is ``not less protective of Apple's rights'' (roughly). Saturday, I loaded the X11 fonts into Squeak, reviewed the licenses that come with the fonts, and immediately unloaded Lucida again ;-). Then, I proceeded to remove all references to the Apple fonts, replacing them with references to Helvetica. After some hacking and garbage collects, I have an Apple font free image.
So, I set out to write a license that protects all rights of Apple, but removes the font clauses. The second bit in the license is the export clause, but as the export clause is not protecting Apple's rights, I felt I could re-word it. The end result is the CleanSqueak license, which I still need to show to a few people (including OSI), before I'm sure that it is Open Source Definition compliant. That's the best I can do, given the terms of the original license (and given the fact that Apple is not willing to re-license Squeak under the APSL - just got that confirmed last Friday).
It's 'MIT' for most of Squeak, but 'GPL' for the VM, basically. I think that's good - you must make available source code to any VM changes, which helps in keeping the core compatible.
FYI, here's the whole thing. Note1: unreviewed by anyone. Note2: this is probably not the most appropriate place to discuss it.
CleanSqueak License
PLEASE READ THIS SOFTWARE LICENSE AGREEMENT "LICENSE" CAREFULLY BEFORE DOWNLOADING THIS SOFTWARE. BY DOWNLOADING THIS SOFTWARE YOU ARE AGREEING TO BE BOUND BY THE TERMS OF THIS LICENSE. IF YOU DO NOT AGREE TO THE TERMS OF THIS LICENSE, DO NOT DOWNLOAD.
PREAMBLE -------- CleanSqueak is a work derived from Squeak. The modifications are both inside the software and to the license, and are made to ensure that CleanSqueak can be licensed under a license that is compliant with the Open Source Definition.
CleanSqueak is a collective work the parts of which many people and organizations hold the copyright to. Specifically:
Copyright (c) 2003 Cees de Groot Copyright (c) 1996 Apple Computer, Inc. Copyright (c) 1997-2001 Walt Disney Company, and/or Copyright (c) 1984-1989, 1994 Adobe Systems Incorporated. Copyright (c) 1988, 1994 Digital Equipment Corporation. Copyright (c) 1996-2003 all invididual contributors.
LICENSE -------
0. Original Contributor, Contribur. "Original Contributor" in this license is Apple Computer, Inc. or its local subsidiary, if any. "Contributors" is the collective of copyright holders to the software or any parts of it, including Original Contributor.
1. License. The software, documentation and any fonts which you will receive by downloading this software (the "Software") are licensed, not sold, to you. Contributors retain title to the Software, and the Software and any copies which this License authorizes you to make are subject to this License. This License grants no right or license under any trademarks, service marks, or tradenames of Contributors.
2. Permitted Uses and Restrictions. This License allows you to copy, install and use the Software on an unlimited number of computers under your direct control. You may modify and create derivative works of the Software ("Modified Software"). You may distribute and sublicense such Modified Software only under the terms of a valid, binding license that makes no representations or warranties on behalf of Contributors, and is no less protective of Contributors and Contributors' rights than this License. If the Modified Software contains modifications, overwrites, replacements, deletions, additions, or ports to new platforms of: (1) the methods of existing class objects or their existing relationships, or (2) any part of the virtual machine, then for so long as the Modified Software is distributed or sublicensed to others, such modified, overwritten, replaced, deleted, added and ported portions of the Modified Software must be made publicly available, preferably by means of download from a website, at no charge under the terms set forth in Exhibit A below. You may transfer your rights under this License provided you transfer this License and a copy of the Software to a party who agrees to accept the terms of this License and destroy any other copies of the Software in your possession. Your rights under this License will terminate automatically without notice from Contributors if you fail to comply with any term(s) of this License.
3. Disclaimer Of Warranty. The Software is pre-release, and untested, or not fully tested. The Software may contain errors that could cause failures or loss of data, and may be incomplete or contain inaccuracies. You expressly acknowledge and agree that use of the Software is at your sole risk. You acknowledge that Original Contributor has not publicly announced, nor promised or guaranteed to you, that Original Contributor will release a final, commercial or any future pre-release version of the Software to you or anyone in the future, and that Original Contributor has no express or implied obligation to announce or introduce a final, commercial or any future pre-release version of the Software or any similar or compatible product, or to continue to offer or support the Software in the future. The Software is provided "AS-IS" and without warranty of any kind of Contributors and Contributors' licensor(s) (for the purposes of Sections 3 and 4, Contributor and Contributors' licensor(s) shall be collectively referred to as "Original Contributor") EXPRESSLY DISCLAIM ALL WARRANTIES AND/OR CONDITIONS, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES AND/OR CONDITIONS OF MERCHANTABILITY OR SATISFACTORY QUALITY AND FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. CONTRIBUTORS DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE SOFTWARE WILL MEET YOUR REQUIREMENTS, OR THAT THE OPERATION OF THE SOFTWARE WILL BE UNINTERRUPTED OR ERROR-FREE, OR THAT DEFECTS IN THE SOFTWARE WILL BE CORRECTED. FURTHERMORE, CONTRIBUTORS DO NOT WARRANT OR MAKE ANY REPRESENTATIONS REGARDING THE USE OR THE RESULTS OF THE USE OF THE SOFTWARE OR RELATED DOCUMENTATION IN TERMS OF THEIR CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE. NO ORAL OR WRITTEN INFORMATION OR ADVICE GIVEN BY ORIGINAL CONTRIBUTOR OR AN AUTHORIZED REPRESENTATIVE OF ORIGINAL CONTRIBUTOR SHALL CREATE A WARRANTY OR IN ANY WAY INCREASE THE SCOPE OF THIS WARRANTY. SHOULD THE SOFTWARE PROVE DEFECTIVE, YOU (AND NOT ANY CONTRIBUTOR OR AN AUTHORIZED REPRESENTATIVE OF ANY CONTRIBUTOR) ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. THE TERMS OF THIS DISCLAIMER DO NOT AFFECT OR PREJUDICE THE STATUTORY RIGHTS OF A CONSUMER ACQUIRING PRODUCTS FROM CONTRIBUTORS OTHERWISE THAN IN THE COURSE OF A BUSINESS, NEITHER DO THEY LIMIT OR EXCLUDE ANY LIABILITY FOR DEATH OR PERSONAL INJURY CAUSED BY NEGLIGENCE OF CONTRIBUTORS.
4. Limitation of Liability. UNDER NO CIRCUMSTANCES, INCLUDING NEGLIGENCE, SHALL CONTRIBUTORS BE LIABLE FOR ANY INCIDENTAL, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO THIS LICENSE. SOME JURISDICTIONS DO NOT ALLOW THE LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES SO THIS LIMITATION MAY NOT APPLY TO YOU. In no event shall Contributors' total liability to you for all damages exceed the amount of fifty dollars ($50.00).
5. Indemnification. You agree to indemnify and hold Contributors harmless from any and all damages, liabilities, costs and expenses (including but not limited to attorneys' fees and costs of suit) incurred by Contributors as a result of any claim, proceeding, and/or judgment to the extent it arises out of or is connected in any manner with the operation, use, distribution or modification of Modified Software, or the combination of Software or Modified Software with other programs; provided that Original Contributor notifies Licensee of any such claim or proceeding in writing, tenders to Licensee the opportunity to defend or settle such claim or proceeding at Licensee's expense, and cooperates with Licensee in defending or settling such claim or proceeding.
6. Export/Import Laws. Software is subject to all export and import laws and restrictions and regulations of the country in which you receive Software and you are solely responsible for ensuring that you do not export, re-export or import Software or any direct product thereof in violation of any such restrictions, laws or regulations, or without all necessary authorizations.
7. Government End Users. If the Software is supplied to the United States Government, the Software is classified as "restricted computer software" as defined in clause 52.227-19 of the FAR. The United States Government's rights to the Software are as provided in clause 52.227-19 of the FAR.
8. Controlling Law and Severability. If there is a local subsidiary of Original Contributor in the country in which the Software License was obtained, then the local law in which the subsidiary sits shall govern this License. Otherwise, this License shall be governed by the laws of the United States and the State of California. If for any reason a court of competent jurisdiction finds any provision, or portion thereof, to be unenforceable, the remainder of this License shall continue in full force and effect.
9. Complete Agreement. This License constitutes the entire agreement between the parties with respect to the use of the Software and supersedes all prior or contemporaneous understandings regarding such subject matter. No amendment to or modification of this License will be binding unless in writing and signed by all parties.
Where the Licensee is located in the province of Quebec, Canada, the following clause applies: The parties hereto confirm that they have requested that this Agreement and all related documents be drafted in English. Les parties ont exige que le present contrat et tous les documents connexes soient rediges en anglais.
EXHIBIT A License. You may copy, install, use, modify and create derivative works of the [Modified Software] "Changed Software" and distribute and sublicense such Changed Software, provided however, that if the Changed Software contains modifications, overwrites, replacements, deletions, additions, or ports to new platforms of: (1) the methods of existing classes objects or their existing relationships, or (2) any part of the virtual machine, then for so long as the Changed Software is distributed or sublicensed to others, such modified, overwritten, replaced, deleted, added and ported portions of the Changed Software must be made publicly available, preferably by means of download from a website, at no charge under the terms of a license that makes no representations or warranties on behalf of any third party, is no less protective of [the licensors of the Modified Software] and its licensors, and contains the terms set forth in Exhibit A below [which should contain the terms of this Exhibit A]. You may distribute and sublicense the [Fonts] only as a part of and for use with Changed Software, and not as a part of or for use with Changed Software that is distributed or sublicensed for a fee or for other valuable consideration.
On Sat, Feb 08, 2003 at 11:02:50AM -0800, Mark S. Miller wrote:
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.
One of the big problems that needs to be addressed is the social one. About two years ago, the Squeak community began an ill-fated attempt to retrofit modularity into Squeak. The resulting design failed to generate the necessary buy-in by the average Squeak hacker. The current SqueakMap work is an alternate attempt at modularity that takes less ambitious steps forward, and has been quite successful so far.
Evolving Squeak to meet the requirements for "level 4" security promises to be even more disruptive to the average programmer. On the other hand, it is my belief that this level of security is necessary for Squeak/Croquet to achieve their dream of revolutionizing personal computing.
So, how can we address this problem? Mark, you mentioned a 2-vm design earlier; there would be a separate VM for Squeak-E within the regular Squeak VM. I don't completely understand how this would work. The following is an attempt to clarify the possibilities of the 2-vm approach.
Assume that Collection and all of its subclasses have been made capability-secure. These classes are, of course, used widely throughout Squeak. Can these secured classes be transparently used by insecure code? From your writings, I gather that they can. How might this work?
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.)
<snip>
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.
Can you give some concrete examples?
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.
The problem isn't "keeping it Smalltalk". I believe that you noted that Smalltalk is more of a philosophy than a particular set of language features. So, if the end result is a better language, I don't think that people will be too concerned if we end up with Smalltalk-04 (or whatever).
The problem is managing the pain along the way. Most Squeak developers won't actively be involved in developing Squeak-E. Take me for instance: I'm busy trying to get my Ph.D. in computer animation, and my wife and I want to get the heck out of Atlanta ASAP. I'm very interested in Squeak-E, and would like to incrementally modify my code to fix whatever breaks as APIs are tamed. But I _need_ the programming environment that I am accustomed to; if Squeak-E can't support the debugger and other development tools, then I fear that the Squeak community will not follow.
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!
They sure do!
<snip>
Joshua
One of the big problems that needs to be addressed is the social one. About two years ago, the Squeak community began an ill-fated attempt to retrofit modularity into Squeak. The resulting design failed to generate the necessary buy-in by the average Squeak hacker. The current SqueakMap work is an alternate attempt at modularity that takes less ambitious steps forward, and has been quite successful so far.
I wholeheartedly agree. One of the major problems that you have to face if you essentially want to "convert a community" is to deal with their expectations. I believe that ultimate goal we are talking about here can be achieved while essentially staying within "current" Squeak for a very long time.
Here's what I'd do: Make your "own class Object" which is considered the base for any future work. Then either slightly modify the compiler (or better: copy the entire enchilada so you have room for modifications) which may (for example) not even know how to compile primitives, how to generate "optimized byte codes" (I know that various people wanted that) and have your "class Object" use it. Make it so that "your class Object" has it's own environment (or whatever you choose to do) for symbols. This will COMPLETELY ISOLATE anything that is done in "unsafe Squeak" from whatever you do in "safe Squeak". With its own set of symbols there is NO WAY that "safe Squeak" can ever send a message that is understood by "unsafe Squeak", there is NO WAY that "safe Squeak" can ever even "name a global" from unsafe Squeak.
I will give you an example for the latter since it is fundamentally important for your work and will show you how efficiently this will isolate the environment you are working in. Let's assume that your environment (and the SafeCompiler) obtains all its symbols from a set named "Foo". Looking up a symbol in Foo will return a different symbol than this in the default symbol set (represented by Symbol's lookup table) so I will prefix a symbol named "bar" looked up in "Foo" by Foo::bar. Now let's write a method in our class EObject (I like the name ;-)
EObject>>tryAnythingBad: aSystemDictionary Smalltalk at: #Array. "try obtaining class array"
If your compiler looks up all of its symbol in Foo, then the above will compile into: Foo::Smalltalk Foo::at: #Foo::Array
Now on to the implications. First of all, there IS NO "Foo::Smalltalk" in global Smalltalk dictionary - you would end up with the compiler telling you that this global does not exist. Neither does "Foo::Array" so that even passing Smalltalk as an argument to that method would not reveil the existence of Smalltalk in that Dictionary. And even *if* you were handed both a reference to Smalltalk and a reference to the #Array symbol from it, Smalltalk would still not understand the message Foo::at:. Consider another bit of code:
thisContext sender.
Even *if* the compiler would allow you access to "thisContext" (which it may not have to but you might implicitly obtain it by creating a block) the message "sender" would (again) translate into Foo::sender which is nothing understood by "unsafe Squeak".
Get it? As long as you stay in your own "symbol set" there is absolutely NO RELATION whatsoever between "unsafe Squeak" and "safe Squeak". Then, you can start to expose certain abilities from "unsafe Squeak" to "safe Squeak" but can do so securely and incrementally. For example, one of the first messages you will want to have in "safe Squeak" is #value (for blocks etc). Since some classes (including BlockContext) are known to the VM you cannot easily make up your own class, but you CAN implement Foo::value in BlockContext along the lines of:
BlockContext>>Foo::value "Invoked from Symbol space Foo" ^self value
Here's something interesting for you. The above essentially grants every object from symbol space Foo to send the message value to obtain the same effect that it would have in the "default symbol space" (Squeak). In other words, Symbol spaces are highly effective (meta) capabilities itself! If the above is compiled in the default symbol space (having the capability to evaluate a block) it can grant this capability to another symbol space (in this case Foo). And Foo - now having this capability - could grant it to another one (or not).
So in short, I believe that there is no need whatsoever to "burn the diskpacks" at this point. The above will give you an entirely isolated space in which you can actually build lots of stuff with room for experimentation, with room for introducing the "right notions" for everything you want (including brands or whatever) and see how this works out. It provides ways for migrating existing code at very little cost. Once it is worked out you are likely to have a much better idea about what parts in the VM really need to be changed in order to be more efficient - but to me, this is quite far ahead.
Cheers, - Andreas
"Joshua 'Schwa' Gargus" schwa@cc.gatech.edu wrote:
Evolving Squeak to meet the requirements for "level 4" security promises to be even more disruptive to the average programmer. On the other hand, it is my belief that this level of security is necessary for Squeak/Croquet to achieve their dream of revolutionizing personal computing.
What does Islands miss in order to be level 4? It allows you to make your own capabilities within the SafeSqueak subset that the Islands compiler runs in by default. As an example, I showed how to do the purses+mints problem, and it was pretty straightforward. Did I miss an email pointing out some hole in my solution?
The annoying part of Islands is the dynamic variables. If you don't trust a capability you are invoking, you have to swap out your island before you invoke it. Likewise, if you are a capability and you don't trust the guy who called you, then you have to swap in a private island during your work.
However, while this swaping code is annoying, it is also straightforward and short. Note that *all* of the dynamic environment gets swapped at once. Thus, while having the dynamic island-wide table of variables is annoying, let it not pass that it transitions Squeak from level 0 to level 4.
This said, there is plenty of room for improvement on Islands. A safe debugger would be great. A way to statically bind to classes would be great. Just please use a different description of the weaknesses of Islands than saying "not level 4". Not only are user-written capabilities available and secure in Islands, but they have been there since early in the project.
As has oft been repeated, the capabilities are the easy part. The hard part is getting the library updated.
Lex Spoon
On Saturday, February 8, 2003, at 02:02 PM, Mark S. Miller wrote:
Rob, I admit I'm a bit confused by your message. Earlier, you wrote:
Mark, I'll admit that I am confused, myself. I am confused about what the right way forward is, when contemplating the changes we need to make to reach level 4.
I still support getting to language-based security, rather than just framework-based, and I realize that this won't be possible without breaking things.
Joshua mentioned the failed modules effort. Part of the reason it failed was because it changed some basic assumptions in the squeak environment and this made it unusable. It left the community behind. The other concern is providing enough functionality so that the people here, for instance, may be able to start using it and making it better. I would love it if that were to happen!
So I am not retreating, but trying to find the balance between having our environment and extending it with inabilities. :) I would like to rename your 'A Coherent Retreat' proposal to 'A Functioning Interim Vat', since I am making good headway on CapTP. It is the area where I can effect some benefit.
I personally am bound into an implementation perspective and I don't have knowledge or experience in the areas being discussed, around scoping and the compiler. Hopefully my comments aren't a distraction to the discussion. I also have some limited time in which to finish what I can, and hopefully incorporate it into squeak. My limitation is that I am working full-time, while doing SqueakE work on the side. In April, sailing season begins again and I expect that I will be on the water every weekend until October, so I won't have but a couple of hours a week to work on this through the summer, and that isn't the kind of time that would allow me to do deep squeaking.
This does not mean that I am opposed, in the long run, to the burn-the-diskpacks approach, only that it should be tempered with the realities of community building, therefore there are several milestones I am thinking in terms of.
First milestone is to see how integrated we can make the eventual sending mechanism into core squeak. This is my goal for April. This requires Andreas' ScriptProcessor, so that we can integrate eventual sending with the average user of Semaphores and sequential scripts. Andreas, if you have a more current version of your core scripting framework, I'd love to see it.
Second milestone is the virtualization layers to support debuggability.
Third is the compiler and language that would provide level 4 security.
There is no reason that they shouldn't be concurrent efforts, but we should point to that feature (system openness) as so important that it deserves its own milestone sooner rather than later.
On Saturday, February 8, 2003, at 06:08 PM, Joshua 'Schwa' Gargus wrote:
I'm very interested in Squeak-E, and would like to incrementally modify my code to fix whatever breaks as APIs are tamed. But I _need_ the programming environment that I am accustomed to; if Squeak-E can't support the debugger and other development tools, then I fear that the Squeak community will not follow.
This is the critical point when a burn-the-diskpacks approach is usable. When it supports the investigation tools to allow us to manipulate it, it will be more broadly usable. Anything we can do to continue working in an environment that currently supports these things, we should take advantage of. This means an approach like Andreas has suggested seems required. This approach will allow us to fundamentally change the language, while still working in our development environment.
On Saturday, February 8, 2003, at 02:02 PM, Mark S. Miller wrote:
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.
When we do this, we should make every attempt to not "lock-down" the security so we can debug it with normal tools, until we can support a debugger and inspector of the right's amplification variety. This tells me that one of the first things we do after getting CapTP and Eventual Sending done, is to build your virtualization layers. :)
We really have two orthogonal directions to take. First is the execution environment and support for tools. The other is the compiler and mutability and plugging leaks in the global scope. If you agree that this seems to be a natural fault line in the work ahead, then perhaps we should form two sub-efforts. The first can look at how to build an inspector and debugger, while the second look at the new Object hierarchy rooted at EObject and it's compiler.
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.)
That's easy enough. We have to change the MOP for our tools. :)
I have been rereading your post on the KeyKOS brand and your comments that this could be placed in a register. In other posts it almost seems that you are separating the lexical scoping from the code. I am trying futilely to separate the different dimensions of an execution environment. You have introduced the concept of ownership into the object graph and the idea that the scope is fixed at the time of creation of an object, rather than retrievable by walking the stack. I can't begin to say that I understand this.
When the ideas are finally understood to the point where there is an implementation with an inspector and debugger, then we would have a usable environment.
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?
Hopefully the MOP replacement for #instVarAt:, will allow us the same functionality.
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.
The fact that this is 1) valuable and 2) something we need anyway, tells me that we ought to make it a first step on the way to the broader changes. That we may be able to do this and maintain mostly backward compatibility is encouraging to me.
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.
This is still a goal, but we need to preserve our environment to get there.
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.
I think it would be too, but it is a long way off. As we strive to get there, let's make sure we keep it a running system.
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).
This then is the big dilemma. We have to have these features of exploration, even when the system gets secured (if you have the capabilities). So we need to implement the ownership and virtualization that you have talked about.
In the meantime, we have to break the feature, not security. If we proceed the other way around, we'll never be secure.
We wont? Why not? Given work on the environment to secure the stack, disable dynamic scoping, and providing for amplifiable inspectors/debuggers, we could support those features. Parallel work in the compiler and symbol spaces, could provide the language-based security we are talking about, but without losing the debuggability feature.
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.
hmm. a dilemma.
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)?
Traits had to subclass some of the Behavior classes to get this to work. Would that be possible in SqueakE? It has nothing to do with dynamic scoping.
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.
I was under the assumption that these systems also walked the stack for exceptions and for debugging. This may not match the strict definition for dynamic scope, but it is openness that could go away without providing an alternative.
I read on your site about a new debugger, that includes a causality pane. Neat idea.
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.
That's an interesting observation. I don't necessarily think that changing the language is bad, and that might dictate a break in backwards compatibility. I am worried about loosing the environment and ability we have in the environment. Some of the discussion to date has informed me that it is possible to support those environment features, and although it is difficult work, it is work that we ought to address sooner than later, so that we always maintain a working environment.
In Lex' Islands work, he still had the debugger and inspector working, but has built a secure space. This is why I state that including Islands in the Interim step is important. It meets that security goal of isolating the space from other parts of the image. If it needs it's own Process, and disallows sharing of objects with other processes, then all the better.
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.
Sure, the ambition may have changed in light of these costs. My main concern is we do this incrementally and preserve our ability to interact with the environment we are building as we go forward. This tells me that level 4 is still achievable, but we would be taking a long road to get there.
This is the only way I can think of that would encourage active participation. Without that, I can;t do it. I don;t have the knowledge, experience, or ability in many of these areas.
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.
I don't mean that protocols cannot change and tools evolve, when I say upwards compatible. It is an environment and tools argument.
I'm sorry fr not making that more clear.
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?
Write access into the meta-scope? It is something I could imagine would be disabled (revoked) for a production deployment.
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.
Interesting. This actually takes us back to the serialization thread. If you pass me a named structure (i.e type) then I should be free to decide into which object i map that structure. I can use any version of the Person class I want to as long as it's structure is compatible with the sent structure.
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.
That uniformity seems to require globally immutable classes. I don't think that this is realistic given the other flexible environment issues we have discussed.
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.
Well, this caused a little spark which is fantastic.
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!
Well, I have updated the package a few times. I needed to repair some bad integration breaks between eventual references, background secretaries (my Vat thread), and Morphic. They don't integrate well.
I hope this clarifies the delicate position I am espousing...
cheers! Rob
squeak-e@lists.squeakfoundation.org
-
Andreas Raab -
cg＠cdegroot.com -
Dean Tribble -
Joshua 'Schwa' Gargus -
Lex Spoon -
Mark S. Miller -
Robert Withers