full isolation

[Lex Spoon]

Alexandre Bergel <bergel at iam.unibe.ch> wrote:
> I have been away these last days, that's why I was pretty silent...
> Would it be possible to set up this list in such a way that when one answers, the answer is sent to the list rather than privately.

This is the Squeak standard, though I have railed against it in the
past.  Here's what convinced me:

	http://www.unicom.com/pw/reply-to-harmful.html

I would request that people do send emails to the list only, and
not CC me.  But if you want to CC me, no technology is going
to prevent that!

> > There has been some murmering about full isolation, both pro and
> > against.  The idea is that modules will be totally insulated from each
> > other and thus unable to cause each other any harm.
> 
> One serious issue concern meta programming. I believe that achieving a
> descent isolation mechanism require a complete overhaul of the reflective
> facility. It seems that the Self mirror mechanism would provide an interesting
> solution...

Hmm.  In practice, it seems like any near-term isolation mechanism is
going to only go so far.  It is okay if certain reflection mechanisms
break isolation, so long as those mechanisms are treated as meta-tools
and not as everyday programming tools.

That said, it's great if you can make more reflective tools follow
isolation restrictions, so long as there is some mechanism around for
programmers to look under the hood when they need to.


> > 	1. Every module must have its own thread.  Otherwise,
> 
> Why ? Classboxes do not impose such a constraint.
> 
> > 	2. Modules must interact by passing messages or events, and not by
> > simple call and return.  Otherwise, when you call, the other module can
> > simply choose not to ever respond.
> 
> ???
> Can you provide a concrete example ?

Here is what I am thinking of:

	EvilWebComponent>>process: webRequest
		[true] whileTrue.


What do you do about this, other than give the thing its own thread? 
And if it has its own thread, you still cannot simply do RPC to that
thread, because the same attack is possible.

These are not my ideas, by the way, even though I am convinced.  This is
the rationale behind E's "vats" system.  I am not convinced that you
have to use something as complicated as E's promise pipelining, but I do
beileve you need to have separate threads and that the underlying
mechanism needs to be based on something asynchronous like messages or
promises.



> Look at the Selector Namespace and Classboxes...

I have looked at it already, and plan to read more about it.  It sounds
like a great way to do things, and I really don't care whether it
achieves full isolation or not.  I remember liking the overall idea
behind it...  but I won't try to summarize that now because I'll botch
it!

I simply worry that if you chase the grail of full isolation, you may be
forced into some unpleasant choices, and it's not necessary anyway.  I
don't think the EvilWebComponent above is a common enough case that it
is necessary to prevent that attack at *every* module boundary. 
Preventing a large class of accidental conflicts, is already a wonderful
improvement; it is not necessary to prevent all conflicts including
malicious ones.



-Lex