I just realized that Dean's message may not have been accepted by the mailing list. Apologies if you see this twice.

X-Sender: agorics@postoffice.pacbell.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 08 Feb 2003 13:19:06 -0800 To: "Mark S. Miller" markm@caplet.com From: Dean Tribble tribble@e-dean.com Subject: RE: [Squeak-e] Comments on Anthony's "...Shared Smalltalk" Cc: Squeak-E - a capability-secure Squeak squeak-e@lists.squeakfoundation.org

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?

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

Cheers, --MarkM