This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Can we sandbox in VisualWorks?
Feed Title: Michael Lucas-Smith
Feed URL: http://www.michaellucassmith.com/site.atom
Feed Description: Smalltalk and my misinterpretations of life
An interesting topic that comes up from time to time is the idea of sandboxing code to achieve better security. So naturally this lends itself to wondering 'can I do it in language X?' type discussions. SmallScript has sandboxing specifically built in to it, but what is required to get a secure sandboxed environment in a Smalltalk like VisualWorks?
The task is to identify how what you can do that you shouldn't be able to do in a Sandboxed environment. Once you've identified those things, you must example how you can limit or remove them.
So, first off the bad - can we make classes? Sure, there's no reason to stop that. There may be some 'reflection' code in the unprotected environment that may now see your class, so that's a gotcha for the people implementing on the other side.
What about compiling? Okay, you can do that too - so long as you don't call primitives.
How will all this work? The basic idea in Sandboxing is to only provide objects to the sandbox that you want them to have. This means, if you give them, say, the Smalltalk object, then can access anything you could if you had the Smalltalk object.
Immediately this suggests that methods like #allInstances and #instVarAt:, #instVarPut: should be disallowed. Yesish, to a degree. #allInstances could be redone to get all the instances, then filter by sandboxes to objects in the calling sandbox.
#instVarAt:/put: are okay so long as you're not doing it to an object you didn't make or not doing it to the bytes in a compiled method. So how do we put these sorts of restrictions in? It all comes back to classes.
To call a method you must first find the method on a class. If I'm given a 'fake' String class that only contains 'safe' methods, then when I try to execute a method on my instance of a 'String' I'll be looking up only those methods that were given to my fake String class.
There are a few critical places we need to make such an arrangement. First of all, it's CompiledMethods and Block's such that a developer cannot change the bytecodes. Second of all it's the Compiler such that it will never compile primitives, it will always does runtime namespace evaluation, etc.
That's all well and good - but what if I give an object in MY class hierarchy to the sandbox? Eg: one of my String's. Then the developer can traverse that hierarchy and find an unsafe method and they're free of the sandbox.
This means any object you go to give to the sandbox must first be 'wrapped up' in to your fake class. A sandbox therefore will always run slower than a non-sandbox, because most of the calls will end up doing a DNU - unless we never implicitly allow calls to original methods, unless we require all methods that work in the sandbox to be explicitly exported.
At this point we've just said we're going to rewrite all the core classes so that there are sandbox safe versions of them.
But it at least does illustrate that this is possible and indeed something that can be ported between Smalltalks as a 'standard sandbox API set'.
I for one have no inclination to begin such a project :)
Previous Topic
