Mark, your review of security possibilities in Squeak is deeply
appreciated.  

Your notion of 4 levels of effort is a great basis of discussion.  In
fact, I believe Islands works at level 4, though it is more awkward for
such thigns than E.  I'll attach my solution to the little-money problem
at the end of the message.  Still, as you guessed, the goal of the
project was more for level 1 or maybe level 2 (eg, retracting sound
access from annoying squeaklets), with hopes of making a basis for level
4.

In this message, I'll first elaborate on some big ideas, and then try to
respond to questions on the details of Islands.  The code example is
atthe very end.  Thus everyone can read as far down as they care too.

The main thing you'll care about is that, during the money exrecise, I
became completely convinced that dynamic class lookups are bad.  They
are a convenient means to the end of reusing Squeak code quickly, but
they mean that to be safe, you have to ensure your own island is running
whenever an untrusted user calls you.  This is a real nuisance! 
Otherwise, even things like integer addition can be a security breach,
because in Squeak this will fall back on language-level code.  Imagine
what could happen if LargeInteger were replaced by something nasty!

There is a big engineering effort to get away from dynamic binding of
class names yet still have limited access to classes.  Happily, though,
the independent modules efforts for Squeak seem to be solving this exact
issue along with their other goals.


The more general dynamic global variables are annoying, but the one case
of World is hard to do away with in Squeak.  World refers to the current
morphic rendering unit.  Currently it is an entire desktop, though in a
Squeaklet it would be more like one page or one subwindow.  From another
viewpoint, World is the root window from XWindows.

Code uses World all over the place: there are 98 direct accesses to the
variable, and 119 senders of #currentWorld.  Plus, there is a tricky
*conceptual* issue with getting rid of the variable.  It's just really
convenient to have the world floating in the ether, and it would suck if
Squeak code became significantly harder to write.  But maybe it can be
done; someone may want to try seeing how many of these method can be
rewritten without the variable!


Note that you don't have to use dynamic variables if you don't want
them.  It's entirely reasonable to think of a future partitioning of
Squeak where none of Morphic runs in any context that needs security,
and thus nothing unsafe is accessing World.  All the other globals
variables seem easy to move around, by attaching the right objects to
World.  If you write code that doesn't use any global variables, and if
we had static binding for classes, then you wouldn't have to fiddle with
installing proper islands before running your code.


On another topic, you say that level-1 success, where you have
completely isolated applets, is useless.  That is not actually true in
Squeak.  The most important goal of Squeak is to allow a new way of
composing electronic documents.  Level-1 success means Squeak documents
can be exchanged safely, which is a huge step forward for Squeak.


Something that is easy to overlook in Islands is that the restricted
class methods are very important.  The class methods that a limited
proxy will execute are *very* limited.  In fact, they are so limited,
that you can always accomplish the same thing the class method does by
inlining the code.  The main thing is that in addition to the regular
restrictions on safe methods, these methods may not access instance
variables.  Any class method that does not follow the restrictions, will
be invisible to anyone who cannot touch raw classes (which is pretty
much everyone, since touching raw classes is an immediate security
problem).


Okay, let me respond to specific questions.


> It seems to me that ObjectInspector can be refactored in a way that would 
> make it both more convenient, and would naturally subdivide authority, 
> simply by currying it. I assume that the listed methods of ObjectInspector 
> are class methods, as shown by the above quoted use. Let's say that all 
> these were instead instance methods, and that ObjectInspector instead had 
> one instance variable and one "new:" class method. Then, instead of writing
> 
>     x := ObjectInspector instVatOf: obj at: i
> 
> you'd write:
> 
>     x := (ObjectInspector new: obj) at: i

I believe this is implemented.  However, the instance methods just call
the class methods.  :)  I guess you'd actually want to use something
other than this exact message sequence to *create* an ObjectInspector
instance, though, in order to defeat using "myObjectInspector class" to
create arbitrary new ObjectInspectors.

Note that the automatic restriction on class methods is pulling weight
in this scenario.

Anyway, I never made a serious pass at secure debugging, and it seems
like a low priority.  It seems very complicated -- e.g., the debugger
itself may have to worry about being corrupted by the code it is
debugging!


> In the section on Literals, you seem to use immutable and read-only as 
> synonyms. I find this confusing. To me, "read-only" means I can observe the 
> current state but modify it. It doesn't mean the state won't change. And if 
> the state to which I have read-only access does change, I expect to be able 
> to observe the new state.
> 
> Do you indeed mean "immutable" everywhere you say "read-only"?

The distinction is unhelpful for Squeak literals.  I suppose immutable
is the better word.  Currently, literals in Squeak change all too often;
specifically, I have a literal change about once a year, and it sucks
when it happens.  :)  Making literals immutable along with read-only is
a terrific thing.  The only time they are mutated in Islands, is when
they are instantiated by the compiler when a method is compiled.



> The section "Dynamic Variable" seems to be to explain only per-process 
> variables. Is this right?
> 

There's a little more to it.  Dynamic variables have a stack of bindings
within each process.  All accesses modify the most deeply nested
binding.  When you pop off the deepest binding, the old binding will
return along with its old value.

As a final tweak, the bindings come a table at a time.  When you install
an island, it installs a new set of bindings (and hides anything not
explicitly listed in the island).  So you can install and uninstall
islands to restore a complete set of predictable bindings.  This idea is
used in the example below.

(Implementation note: I never made an island-creating capability for
Islands, and I never implemented a thisIsland facility for grabbing the
island you are running in.  It seems like these would be very easy,
however.)


> This section refers to "methods that are marked as privileged". Even after 
> reading the later section that explains this, I didn't feel like I 
> understood how this marking happens, or how the authority to do this marking 
> is controlled.

You mark it by sending messages to the real, low-level class object, the
same class object that the VM uses.  Thus it is as privilaged as it can
be.

I really hope that Islands reaches the 4th level of success that you
talk about, in which case normal users never need to write privilaged
methods.  Who needs to define primitives, or access variables from the
system's most privilaged island, or touch thisContext?  Logically no
one, and hopefully this works out in practice.


> Can the same dynamic-variable-using instance be invoked from different 
> processes (causing different bindings of the same use-occurrence of the same 
> variable), or are dynamic-variable-using instance partitioned among the 
> processes that can invoke them. Unfortunately, I suspect it's the first, but 
> I'll wait to find out before arguing against it.

It's possible for it to be the first.  For example, if a squeaklet forks
a thread, then the thread will surely be given the same island and thus
the same bindings.

It is perfectly reasonable, though, for secure code to keep track of a
predictable island for its own use.  When you install an island you have
created, you get no accidental variable bindings.


> >Whenever code is loaded from untrusted sources, it should be loaded into 
> >unprivileged methods.
> 
> I'm not sure how to read this. If the code includes methods that were 
> written assuming they would run privileged, what happens?

A compile error.


> >Processes with direct access to
> 
> I don't understand what this means, but it alarms me. In a capability 
> system, we should be speaking only of objects having access to other 
> objects. I know that Processes are objects, which is good, but I don't think 
> this accounts for what you mean.

I'm not sure what sentense this was.  Process is probably the wrong
word, and island should be used instead.



> Are restricted classes (as implemented by the restricting proxy) read-only? 
> (I mean, genuinely read-only, not immutable.) I think they should be.

Yes, that's part of the point.  Incidentally, all classes are restricted
unless you have a "SystemIsland" installed.  It just doesn't seem like
the more powerful features of classes are very useful in practice.  For
example, how often do you really need a class instance variable instead
of a regular class variable?  Privilaged class methods also become a
convenient place to stick methods that only privilaged code be using;
there is no way for unprivilaged code to directly invoke such methods.


> > In particular, many class methods return "self"
> 
> This reminded me that Smalltalk methods by default return self. E had a 
> different but similarly dangerous policy. We found to our terror that this 
> was a pervasive source of accidental security holes in our code, very much 
> along the lines of the specific security hole you found with classes. Rather 
> than making a custom repair for each individual case, I fear that you'll 
> find you'll want returns-to-SafeSqueak to return null, rather than self, by 
> default. This is the first issue I've encountered that makes Java easier to 
> tame than Squeak. In Java, methods are void return by "default". ("default" 
> is a funny word. It's still explicit, but is the path of least resistance.)

I believe I solved this quite sufficiently, however.  There aren't any
more specific cases.  When you run a method on a restricted class proxy,
then anything that method can do, you can already do yourself.

Smalltalk doesn't have many statement types.  All of them can be
reviewed.  I haven't done it *real* carefully, but it ceartinly seems
like anything a restricted class method can do, the caller of that
method could do already, with the one exception of instantiating
classes.  The other statements are things like creating temporary
variables, sending messages to objects you already have, creating
literals, creating blocks, and so on.

My intuition for this design approach is that class  methods fall into
three categories:

	1. Utility methods, eg returning a constant.  These need no privilage.

	2. Instantiation methods.  Except for #new itself, these are the same
as #1.

	3. Primitives.  These should not be directly accessible in restricted
contexts.

The Islands solution allows for #1 automatically, and for the two
necessary methods in #2 (basicNew and basicNew:) to be punched through
explicitly.  Eliminating #3 automatically is a nice side benefit, which
means that a lot of legacy code doesn't have to be rewritten
immediately.

Incidentally, this notion of super-safe mehods is useful for instance
methods, as well. If you are auditing proxies, then you can immediately
ignore super-safe methods.


Also incidentally, my favorite solution to this problem would be to get
rid of class methods.  Even if we have to write explicit factories like
the Java guys, it would simplify Smalltalk so much that it may well be
worth it.  This analysis and solution to class methods are probably the
hardest part of Islands, and yet class methods are supposed to be
simplifying things!  (Alternatively, the class-ish methods and the
utility-ish methods of classes could be separate aspects of some kind,
eg using Nathanael's and Stephen's "Traits", but this is starting to
make my head spin.  I'll let them try, if they want to!)



> >An incomplete list of such methods is the following:
> 
> I would be very interested to see the complete list of methods on Class, 
> ClassDescription, Behavior, and Object that you consider safe. It's much 
> more important to review the list of what's allowed than the list of what's 
> disallowed (though you made the right choice of which to list for the paper).
> 

It's an algorithmic definition.  The compiler automatically marks which
methods stay within the super-safe subset of Smalltalk described above,
and proxies check whether this mark is present.

This is why there is no list of rejected methods.  I agree that having a
reject list is easy to screw up with.



> I don't understand why you allow instaVarAt: and instVatAt:put: on 
> non-proxies? Does this include non-proxies written in SafeSqueak?

Umm, you don't have to except for legacy code.  However, it loses
nothing for non-proxies.  If instVarAt: is unsafe, then the object
should probably be a proxy.

The idea is that if you instatiate a normal object, then you already can
get access to all the things the object will have in its instance
variables.  And if that is true, then you can extend the argument used
above with super-safe class methods: you cannot do anything with
instVarAt:, or by calling any method compiled in restricted mode, that
you could not do with your own code.

Thus, it's almost a definition: Proxies are objects which protect their
instance variables from outsiders.  The name "proxy" thus works very
well (though I'm not sure I had all this in mind at the time the word
was chosen!)


> 
> I completely did not understand the section "Characters and Symbols", 
> probably because of my ignorance of modern Smalltalks. Could you expand?

The issue is that both characters and symbols should be == whenever they
are =.  For example:

	(Character value: 10) == (Character value: 10)

To accomplish this, there must be a system-wide table of characters and
symbols.  Currently these are in a class variable (incidentally, Islands
was still secure before this work was done -- it was just that creating
characters and symbols from their constituents did not work, outside of
literals.)

Thus, the two creation methods (#value: and #intern:) for these classes
are made into instance methods of capability objects.



> >This proxy might or might not immediately install the cursor as requested, 
> >depending on the precise security policy that is being implemented.
> 
> Implemented by whom, how? This is the first I've seen of "security policy" 
> used this way.

Similarly, installing a cursor is accomplished by sending a method to a
known global variable.  (It could just as well be an instance method of
the world....)  Depending on what is in that variable, the cursor will
become the hardware cursor, or something else will happen.

In order for an island to change the hardware cursor, it will have to be
given the capability that influences the hardware cursor from outside.



> I would hope to convince you that shared-memory multi-threading, locks, 
> semaphores and such should not be part of SafeSqueak. But, scoping and 
> partitioning issues aside, this is a mostly separate discussion we can leave 
> till another time.

Interesting thought.  They often get you in trouble, anyway, just from
accidental problems.  :)


> You don't actually explain what the issue is with Exceptions.

Exceptions, like many things in Squeak, are implemented in
Smalltalk-level code.  They start with thisContext and then trace around
the call stack.  Instances of exceptions actually have contexts stored
in instance variables.

Access to stack frames has not been secured at all, and it seems
difficult to do so.  Further, there is little use for it in a restricted
context.  It's a neat exercise to try and come up with safe access to
stack frames, but instead I went after the easier problem of nailing
down exceptions.

Only, well, it's still hard.  A complication is that users can write
subclasses of exception and have their code run!  My idea for Isladns
was that, to get things going, you could only *define* new subclasses of
Exception, and that you could not add any method to them.  This solves
most uses of exceptions, but it's a kludge and it should be rethought at
some point.  Most likely, Exceptions are screwed up in Islands in
multiple places.


> >In particular, the following primitives should be disabled:
> >
> >* instVarAt: and instVarAt:put:, because they allow directly breaking 
> >  confinement
> >
> >* at:, basicAt:, at:put:, and basicAt:put:, if the proxy has indexed fields, 
> >  because they would allow directly breaking confinement
> 
> I think I understand the others, but what's the problem with #at: and #at:put: ?

It's the same with instVarAt: and instVarAtPut:, only for indexed
(numbered) variables instead of named variables.  Arrays are probably
unlikely to be used as proxies, but then again it's extremely easy to
block, anyway.


> 
> >Additionally, #shallowCopy and #clone make revocation much more difficult; 
> >thus, they should most likely be overridden to return the receiver instead 
> >of returning a true copy.
> 
> If you can't support their contract (and indeed you can't), then shouldn't 
> you just suppress them?

It's already allowed in Squeak.  For example, "3 clone" returns 3. 
Arguably, #shallowCopy should be general and #clone should insist on a
real copy, but that's not the way the contracts are right now.



> >Note that all non-primitive methods from class Object may be safely left 
> >accessible. Since such code must consist of message sends between 
> >parameters, self, and globals, user code could emulate the code even it it 
> >were disabled, and so disabling such methods gives no gain in security.
> 
> Are all the globals accessible from methods on Object necessarily accessible 
> by both callers and subclasses?

Not right now, due to the dynamic binding of globals.

There probably aren't many globals floating around up there except for
classes, though, so reviewing all the code may not be as tedious as it
sounds.



> 
> >A primary advantage of the submemories approach is that there is no need to 
> >add a special kind of cross-memory oop
> 
> Given the stated purpose of submemories, you need to be able to reclaim a 
> submemory without being able to reclaim the parent memory. This means that 
> oops from the parent into the sub need to spontaneously seem to become some 
> innocuous object (like null) when this happens. I think you will find 
> support for this hard at fine-grain. E supports this only between vats, 
> where there's an enforced indirection through intermediate objects anyway, 
> and where the possibility of partition is part of the semantics anyway.
> 

I dunno, it seems like you could do an allObjectsDo: inside the VM and
look for instance variables pointing into the submemory.  Remember than
in Squeak, we do have easy access to the VM.


> In any case, I recommend postponing further worry about resource controls 
> and denial of service until these other issues settle down.

Agreed.



Okay, here's my solution to the money problem.


Mint, Purse are normal classes with a rich set of methods.  The only
strange thing is that, Mints instances know of some "money island",
which should be easily created via something like "Island new".  Money
island has all the normal classes installed.

LimitedMint, LimitedPurse are a subclasses of LimitedProxy, and these
are what restricted code will see.  Probably this is a common pattern in
Smalltalk capability implementations, since there are no private
methods.

Here are the interesting methods.

=====================================================
LimitedPurse>>deposit: rawAmount from: rawOtherPurse
	| amount otherPurse |
	amount := self safeIntegerFrom: rawAmount.
	(self hasSameClassAs: rawPurse) ifFalse: [
		self error: 'invalid purse supplied' ].
	otherPurse := rawOtherPurse realPurseOnBehalfOf: self.


	purse mint moneyIsland installDuring: [
		purse mint == otherPurse mint ifFalse: [
			self error: 'incompatible mints' ].

		amount < 0 ifTrue: [
			self error: 'only positive amounts may be deposited' ].

		otherPurse decreaseBalance: amount.
		purse increaseBalance: amount. ].



realPurseOnBehalfOf: aLimitedPurse
	(self hasSameClassAs: aLimitedPurse) ifTrue: [
		^purse ]


LimitedMint>>newPurse: rawStartingBalance
	| startingBalance realPurse newPurse |
	startingBalance := self safeIntegerFor:  rawStartingBalance.

	mint moneyIsland installDuring: [
		startingBalance < 0 ifTrue: [ self error: 'initial balance must be non-negative' ].
		realPurse := mint newPurseWithBalance: startingBalance.
		newPurse := LimitedPurse new initialize: realPurse ].
	^newPurse.



LimitedPurse>>initialize: realPurseToUse
	purse == nil ifFalse: [ self error: 'dual initialization' ].
	purse := realPurseToUse.

=====================================================


Four things seem interesting:

	1. There is a ton of code doing input validation.  This seems unavoidable with objects-as-capabilities, because callers can pass you any object they please.  Some automation would probably be helpful.  For example, it looks like E's soft typing is making the E solution shorter (and more reliable).  As is, there are a bunch of things in RestrictedProxy such as safeIntegerFor: which will halt execution on bad input.

	2. There is no direct support for sealers and unsealers, so the code uses a method realPurseOnBehalfOf:, which in turn relies on hasSameClassAs: to detect valid objects.  I believe Sealers and Unsealers, however, could be implemented even within SafeSqueak.  (I never saw the point of such a facility until doing this exercise, incidentally -- it's a good one!)

	3. Every time the code calls across to a real Mint or Purse object, it has to set the island to Money Island.  So the limited methods mostly have the pattern: check arguments, install a sane island, and do the real work inside the sane island.  With static binding, this wouldn't be necessary.

	4. You have to explicitly check for dual initialization, since construction methods are just normal methods in Smalltalk.


Lex Spoon