This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: SandboxedSmalltalk Feed Title: Michael Lucas-Smith Feed URL: http://www.michaellucassmith.com/site.atom Feed Description: Smalltalk and my misinterpretations of life Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Michael Lucas-Smith

I've always wanted to be able to run Smalltalk code that is untrusted in my images along-side all my other code and know it's not going to do me or my machine any harm.

But this feature is not part of a Smalltalk VM. Not only can the VM not guarantee this, but even if it could, it wouldn't be able to do it on a per-process basis inside the image.

I've thought about a sandboxed Smalltalk for a long time now and I've even blogged on it before. Previous thoughts have always been along the lines of "Proxy objects" that control everything or "Method Wrappers" that control everything. Both of these techniques turned out to be wildly unpredictable in terms of stability and control.

Instead, I decided it was high time I controlled the Process. If I do that, then I can control what messages are sent, to who and with what arguments. With that kind of control I can secure the image in any way I want.

But unfortunately, trying to control a Process using the debug commands turned out to be very hard - you have to know a lot about the current context and what will happen next to really control the thing properly. I gave up on this idea.

Instead! I've managed to make a system that execute Source Code Parse Trees!. Using this process, I have complete control over what is happening and I'm not so deep in the VM context's that it's also quite easy to do. The only draw back is that it runs quite slowly in comparison to the VM (obviously) but not so slow that it's completely painful to use.

The package is called SandboxedSmalltalk and there is a tests package called SandboxedSmalltalkTests. Once you have them loaded up you can execute the following kind of code:

'1 + 2' sandboxExecute

Or to get in to actual policy control of the process:

'self newTCPserverAtPort: 12345' sandboxExecuteOn: SocketAccessor policies: [:c | c addPolicy: SbExecutionPolicyNoOSHandles]

There are several policies in place now. They are:

• SbExecutionPolicyNoTranscript - this will disallow any access to the Transcript. This is enabled by default, as the SandboxedSmalltalk process is not able to write to the Transcript due to the manner in which the Transcript does its locking.
• SbExecutionPolicyNoReflection - this disallows all the meta reflection provided by ClassDescription, Class and Metaclass.
• SbExecutionPolicyNoOSHandles - this disallows any access to any kind of OSHandle. These range from files to sockets, etc.
• SbExecutionPolicyGraphics - this disallows any kind of graphical access from graphic contexts to graphic mediums.
• SbExecutionPolicyNoDirectAccess - this disallows any kind of instVarAt:put:, become's, etc. These are mostly primitives that are blocked.
• SbExecutionPolicyDebug - this forces the processes to write every step it makes to the Transcript. Use this for debugging.

The important thing now is for other Smalltalkers to try this package out and test the boundaries of these policies. It would be ideal if people could contribute tests that break the security as well as code to fix those breakages. As a group, we can end up with a nice set of restriction policies that can be mixed and matched accordingly.