Dean_Swan at Mitel.COM wrote:
> What is the benefit of doing this when compared to simply lauching an image with
> limited capabilities in another instance of the VM running under the host
> operating system?

Well, it would basically work.

But it makes it hard to do smarter security things.  For example, what
if you only want to allow FFI when it is used by Balloon?  Harder, what
if you want to write a browser within Squeak itself, which caches pages
to the file system?

Both of these examples are trivial with in-image capabilities.  They are
much harder if you have to do the checks from within the VM.


Anyway, it's certainly possible compare the approaches by thinking of VM
primitives as capabilities.  It's just that:

	1. You have to implement VM primitives--including any security
checks--in Slang.

	2. You have to make all of them available to the entire image.  So you
can't allow just certain objects to use certain primitives.  (well, not
easily).

	3. You can't create any new ones on the fly.


These are harsh restrictions.  Probably you end up severely limitting
what the VM allows you to do.


> Is this intended to support remote users of a server type application?  If so, I
> think Squeak has a real limitation in the way it implements multi-threading.
> Something would need to be done to keep a "client" method from hogging all of
> the CPU, which even an otherwise harmless method, operating in a "sterile"
> environment could still do.  This would amount to a "denial of service" attack.

Denial of service is certainly an issue.  I didn't want to mention it
until someone thought of it on their own.  (The system has a lot of
details to think about as is, eh?)  :)

Anyway, CPU DoS's can be fixed in two ways:

	1. run a sand castle at a lower priority, if you only have one sand
castle loaded.

	2. run a high-priority task switcher, if you want to allow for more
than one at a time.


Memory DoS's are harder but not too much so.  The best approach I think
would be to have a separate ObjectMemory for each sandbox.  new and new:
allocate from whichever ObjectMemory is currently active.  I can't whip
this up, but I'm sure there are VM hackers out there for whom it would
be a breeze.


> Other than supporting multi-user/server type applications, with user programming
> capability, I can't think of anything that this "buys you" for the amount of
> complexity it seems to require.


Overall, it's both natural and powerful.  You can go a certain ways by
lobotimizing the VM, but you can go much further with in-image
capabilities.  It's a framework that supports most any security policy
you can dream up, usually pretty easily.


And besides, what's wrong with multi-user applications??  :)  I like the
fact that this is an important step towards a multi-user SqueakOS,
should anyone ever want to go after that.


-Lex