SecureSqueak

On Thu, Mar 18, 2010 at 3:42 PM, Chris Muller <[hidden email]> wrote:
> Yes, I have always found your project interesting, even if I don't
> understand it.  For immutability I understand that blocking
> basicAt:put:, instVarAt:put:, the Compiler, etc., might help for
> secure immutability from attackers, but can you support object
> serialization?  Beyond that, I was curious about is whether
> SecureSqueak addresses how to prevent an attacker from using any
> object as a confused deputy.  Or from changing someone's name from
> Peter to Paul, etc.  Does SecureSqueak employ capabilities to address
> these issues?

The general idea behind SecureSqueak isn't too complicated. When the
user clicks on some link in the UI or somehow causes remote code to be
loaded over a network connection, that remote code (bytecodes,
effectively) will be loaded into the image and executed. The idea
behind SecureSqueak is that untrusted code can't do any harm to any
other code or objects in the image; the only things that remote code
has access to is a window to draw in, events from the UI when that
window is active, and maybe some services it needs access to such as
logging. So it's basically like a web browser, but for Smalltalk code
rather than HTML.

Serialization is implemented manually by each class. I prefer this
way: you only serialize the object state that needs to be serialized,
and you can choose the most efficient way of serializing that state.

As with the confused deputy (which I assume is an object that
overrides doesNotUnderstand: with minimal implemented methods), I'm
going to be adding a whole lot of ways of verifying the authenticity
of an object.

I don't understand the attack about changing somebodies' name. Objects
won't have access to the SystemDictionary (unless they ask really
nicely), if that's what you're referring to.

I should be making a release of SecureSqueak (0.2) sometime soon, but
it won't be a very interesting or secure one. I'm still a couple of
years away from the really interesting stuff. No rush, right :-).

Gulik.


--
http://gulik.pbwiki.com/

In my opinion, if you want to grab some code off the internet and run
it in a sandbox, you should spawn a slave image and run it inside that
image.  The VM should ensure that any important requests have to go
through the master image.

In the same way, Croquet really ought to run each island as a separate
image.  The UI ought to be able to look into each island to display
it.  This would make it easy to prvent cross-island references.

Similarly, the way to write parallel programs is to spawn an image for
each core. In general, a single image should be a single process.  It
should be easy to develop an application that consists of a set of
images.

-Ralph Johnson

On Thu, Mar 18, 2010 at 11:25 AM, Ralph Johnson <[hidden email]> wrote:

On Mar 18, 2010, at 8:25 AM, Ralph Johnson wrote:

> In my opinion, if you want to grab some code off the internet and run
> it in a sandbox, you should spawn a slave image and run it inside that
> image.  The VM should ensure that any important requests have to go
> through the master image.
>


This is a pragmatic approach, but to say that this is all that you'll ever need is akin to saying that there isn't any reason for E to exist.  I'm glad that there are people like Gulik and Mark Miller who are trying to attack the hard problem.


> In the same way, Croquet really ought to run each island as a separate
> image.  


Our experience shows that the right direction may be to have a large number of fine-granularity islands.  In such an architecture, it's not feasible to run each island in it's own image, since at the very least you would lose fine-grained control over scheduling (i.e. you would be at the mercy of the platform scheduler).  However, I agree what you say below:  to have 1 image per core and to distribute the islands between these images.


> The UI ought to be able to look into each island to display
> it.  This would make it easy to prvent cross-island references.
>


Could you elaborate on how you see this working?  Traversing a 3D scene-graph involves touching a lot of objects, and it seems inefficient to have a master image essentially send IPC requests to slave images to perform the traversal (maybe I'm reading the words "look into" too literally?).


> Similarly, the way to write parallel programs is to spawn an image for
> each core. In general, a single image should be a single process.  It
> should be easy to develop an application that consists of a set of
> images.
>


Agreed.  We have a great start for this with HydraVM.  Hopefully we find the energy to finish the job.

(Wow, why didn't we think of HydraVM as a Google Summer of Code idea?)

Cheers,
Josh



> -Ralph Johnson
>

On 18 March 2010 18:11, Josh Gargus <[hidden email]> wrote: Hey, i'm still having a lot of aces hidden in my sleeve , ready to be drawn :)
The last thing, i did with it is attempt to move closer to model,
where you can spawn a tiny object memory
from a main, big one, aimed for limited set of tasks.
Also, i got an island model, which can be adopted in Hydra, which
would allow us to have a cross-island references
and send messages between them.
There's a lot of ideas floating in my mind.. i hope that Cog will be
released soon, so we could start making next-gen things
based on a next-gen VM :)

> Cheers,
> Josh
>
>
>
>> -Ralph Johnson
>>



--
Best regards,
Igor Stasenko AKA sig.

On Fri, Mar 19, 2010 at 4:25 AM, Ralph Johnson <[hidden email]> wrote:
You could do it that way. You'd have a different set of issues to work
through though, such as inter-image communication.

As with concurrency, I think time is much better spent improving
support for the concurrency that we already have: green threads on a
single CPU core. The debugger, scheduler, and UI could all be
improved. There's no point in making the VM able to use multiple cores
unless we actually have concurrent code to run and problems to solve.

Gulik.

--
http://gulik.pbwiki.com/