[sldev] Scripting projects priority survey

[Michael Schlenker]

Am 25.06.2008 um 20:46 schrieb Argent:

> On Wed, Jun 25, 2008 at 11:59 AM, John Hurliman <jhurliman at jhurliman.org 
> > wrote:
> The idea is to run code in a sandbox using a customized version of  
> Mono (open source implementation of the .NET runtime/framework). To  
> do anything clever in any language you need functions that let you  
> do clever things. For example, peeking at memory you shouldn't see  
> requires a function that lets you look at memory, or a pointer that  
> you can manipulate to point outside where it should see. The sandbox  
> removes all unsafe code (unsafe in this context meaning code marked  
> with the unsafe keyword which gives you access to pointers) and is  
> not compiled with any framework except for LL's API. You end up with  
> something that is no less secure than the original LSL language, but  
> you're coding in a more refined syntax that compiles to a common  
> instruction set.
>
> I've implemented "inherently secure" languages for real-time control  
> systems, web frameworks, and user-side scripting, and I've also  
> followed the development of the Java sandbox (and found some  
> security flaws in their proxy handling for them). I've found that  
> it's not as simple as removing all code that gives you access to  
> pointers: you have to examine every component that you're going to  
> make available through the language to make sure that it conforms to  
> the same protection model that you're trying to implement. Most  
> common components do satisfy that constraint, but not always, so you  
> do have to audit everything you add. And the exposed C# runtime will  
> have to be a superset of the LSL one... providing access to more  
> capable components is one of the reasons for doing this.
>
> Have a look at the kinds of odd interactions the Javascript runtime  
> (which is "inherently safe" in this sense) has run afoul of, to get  
> an idea of what it would take to incorporate any rich scripting  
> language like Python or Lua or Tcl.

Tcl and Lua might be the easiest from a security standpoint, at least  
Tcl has a similar sandbox model and you can quite safely strip out any  
non wanted functionality. But fully agreed with your statment that its  
a huge task to security review all those modules you might give access  
to. Another example of stripped down environment which faces similar  
problems might be the nearly crippled python subsystem in Google App  
Engine.

Michael