[sldev] Scripting projects priority survey

[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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080625/33ca6f3c/attachment.htm