I have one nit to pick.


On Sun, Jan 26, 2003 at 08:09:36PM +0000, cg at cdegroot.com wrote:
> I think your analysis is correct. I've been thinking about doing this as
> part of the modular Squeak thingy that should start this year - strip
> Squeak to the bare bones (I call it 'Kernel Squeak'), and secure it.

This sounds great.


> Then, load the lot and ship it (the environment I call 'Core Squeak',
> with development environment, readme, Morphic, whatever). Now, package
> by package, pick it apart, audit it, lock it down, and declare it
> secure. Continue until Core Squeak consists wholly of packages declared
> secure.

I disagree.  If you do it right, then the stuff you load is secure
automatically.  However, it may not function correctly.  So what you
have to do with each package is punch holes in the security
restrictions.  I've punched  enough through that you can run
BouncingAtomsMorph very slowly.

With most packages, you won't need to punch any holes.  How often does
a package need its own primitives?  Message sends and variable accesses
are secure automatically, due to the use of objects-as-capabilities.
The only way you can do something bad is:

	1. invoke a primitive 
	2. send a message to a capability object

If your capabilities are secure, then loading code that doesn't have its
own primitives is safe.  (Well, plus you can't let "loading code"
include screwing with the class hierarchy too badly.)

If an approach requires auditing everything, then the approach
is too difficult to be useful for most purposes.  Who wants to
audit all of Morphic?

-Lex