I think it's important to think in terms of capabilities, not segmenting
the image and such.  The system really needs to be redesigned from the
ground up to take capability based security into account.  There are a
couple of things that we need before we can actually tackle it
however...we need a good meta object protocol that will enable an object
to protect direct access to it's state (i.e. #instVarAt:put: and friends
should be usable only indirectly through some reflection object).  The
MOP also needs to enable any object to fully replicate the protocol of
another object...which would probably require both delegation and the
ability to provide custome message responders (overriding the normal
message lookup).  We also need to re-design the current meta model from
the ground up (allowing for name spaces, environment, etc).

Then, objects could provide façades that offer more restricted
capabilities and which would prevent any direct access to the façade's
state (i.e. the underlying object reference).

The VM would probably also need some way of enclosing object references
in some sort of cryptographically secure envelope that would enable only
the designated recipient to access the object reference.

Once you have these foundations in place, then you could conceivably
design a system where capabilities are protected by controlling object
references.  Each "door" that is "unlocked" in the system would expose
some set of capabilities by opening up access to some set of objects.  I
imagine that using this system, you could even design a processor
scheduling system that would be resilient to denial of service types of
attack.

I think http://erights.org/ has some good information on this topic.

- Stephen

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Lex Spoon
> Sent: Saturday, January 25, 2003 4:41 PM
> To: squeak-dev
> Subject: in-image security with multiple image segments
> 
> 
> 
> The topic is in-image security.  You have multiple bunches 
> of objects in an image, and one bunch might try to harm 
> another bunch.  You could use separate OS processes and 
> hardware memory protection to protect these bunches from each 
> other, but that makes it hard for *nice* bunches of objects 
> to cooperate with each other.  Thus, it would be nice to load 
> them all together into the same image, so that they can 
> cooperate conveniently.
> 
> The common sense of many people is that to have practical 
> security, you divide these objects into some sort of memory 
> segments.  Those segments might be called islands, vats, 
> environments, or even something else. 
> I'll go with that for now, though it's hardly obvious that 
> this is "the" way to do in-image security.  (eg, you may want 
> to just use individual
> objects!!)
> 
> 
> A further intuition many people have is that these segments 
> should completely segregated so that there are *no* pointers 
> between the images.  That approach boils down to having 
> separate Squeak processes (at the OS level), and so it 
> doesn't sound much like in-image security. 
> Thus it isn't right to have super-strong protection between 
> images (unless you want to give up on in-image security).
> 
> On the other hand, you can't have completely normal pointers 
> between the images, can you?  If you did, then you'd 
> essentially just have one virtual segment that is arranged as 
> a normal one.  You have to either have a new kind of pointer, 
> or to have checks in the VM for every normal pointer that 
> crosses a segment boundary.  More on this later.
> 
> Now we have special pointers between image segments.  How 
> much can they be used?  We are probably assuming, for 
> example, that the entire content of one image segment has 
> become hostile.  In that case, your special pointers better 
> be limited enough that any valid access to them cannot cause harm.
> 
> What kinds of restrictions would you place?  In the "Islands" 
> work I did a few years ago, the restrictions were 
> frustratingly strict.  They go something like:
> 
> 	1. You do not pass across arguments verbatim: you first 
> sanitize them. 
> If you pass an argument across, then the other segment is 
> suddenly polluted with an arbitrary pointer back into your 
> space, and remember that we are trying to carefully control 
> the pointers between spaces. 
> For simple data like numbers and strings, you can copy the 
> data before passing it across.  For more complex data, you 
> can either copy it, or you can provide a new special pointer 
> to it that you pass across. 
> That's a pain, so you try to avoid it.
> 
> 	2. Similarly, you do not pass the response back 
> verbatim.  The solutions are identical.
> 
> 	3. You do not create new inter-segment pointers 
> arbirtarily.  Each inter-segment pointer is giving the 
> segment a new capability (in the security sense) and thus it 
> needs to done carefully.  The nice thing is that you can only 
> get a new inter-segment pointer (assuming the VM is tweaked 
> in various little ways) by accessing an existing 
> inter-segment pointer.  Assuming you don't have too many 
> pointers between image segments, your task as a security 
> auditor isn't that hard.
> 
> 
> Something to think about is what kind of help you get from VM 
> support for segments.  If you automate everything, eg 
> automatically creating an inter-segment pointer from a normal 
> pointer if it is passed to the other image, then you gain 
> nothing that I can see.
> 
> In fact, you don't *have* to have VM support.  There is no 
> "special pointer" in my "Islands" work.  Instead, the 
> programmer must keep track of everything.  It's not 
> particularly hard, BUT you get no protection if some obscure 
> pointer is incorrect.  While it is unclear how much it helps 
> to have VM help, it is certain that you can get some.  The 
> question is, how should things be arranged?
> 
> I'm not sure.  But consider the case of an arbitrary morph in 
> one segment, and a World in the other segment that is trying 
> to draw the morph.  Now devise a secure way for this guy to 
> draw, with bonus points if your solution is efficient.  The 
> underlying morph is going to send commands back out to the 
> outside world, and the underlying morph is going to get input 
> events somehow.  (In Islands, I did this by having a world 
> within a world, and thus keeping the communication fairly 
> thin.  I hacked the performance a little by letting the 
> morph's island and the world's island have shared access to 
> the bitmaps of a form, and then those bits could be copied 
> out into the world's display...  An alternative solution is 
> to use something like Nebraska to talk across the connection....)
> 
> 
> Lex
> 
>