[squeak-dev] Running untrusted code & sandboxing

Igor Stasenko siguctua at gmail.com
Sat Jan 9 11:30:43 UTC 2010


Hello all,
I am thinking, what could be done to make Squeak 100% safe when
running untrusted code.

>From one side, stands a compiler, but from another is run time environment.
What i thinking that untrusted code should use own, sepatate
class/object hierarchy and
do not use any of existing objects from 'unsafe' part of image.

If we could use a separation in image, like:

[ core [ unsafe ] ]

where 'core' is our regular image, or dev image. It is safe to have a
references from objects in regular space to ones in unsafe one.
But we should prevent leaking a reference to objects in 'core' area
being captured by any objects in 'unsafe' area,
where untrusted code runs.

Ultimately, before running an untrusted code, we should swap the
specialObjectsArray, so all things, which VM primitives could see,
will be pointing inside unsafe space, and therefore we making
impossible to obtain a pointer to any object from 'core' area
even when using primitives.

But then, once we switch a specialObjectsArray, and if there is no
objects pointing back to core, VM will GC it mercilessly.
And of course, once untrusted code finished its job, or interrupt
occurs, we should be able to switch whole VM context back to core.

So, there should be a pointer back to core area. But once we have it,
we have a chance that malicious code could find it
and break from the jail.
Well, maybe with help of specialized compiler, which knows what
primitives are unsafe, we could hide this reference?

Any other ideas in this regard?

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list