Lex,

Interesting ... but what's your point?! I fail to get the message here
possibly because of the confusing use of words like "pointer" (which - to me
- imply the ability to manipulate them as in C/C++), "data" and similar. For
example, what is an "incorrect pointer" in Squeak and how could one create
it? Also, are you arguing for or against "separate image segments" or
neither?! I'm having real trouble trying to figure out what you're saying
here...

Cheers,
  - Andreas

> -----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 10: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
>