Re: Survey of lua sandboxes?

[David Favro <lua@...>]

Hello Gé,

On 12/26/2011 03:31 PM, Gé Weijers wrote:

> What comes to mind in sandboxing Lua:
> 
>   * disable the code path that loads compiled VM code altogether, in the Lua
>     C source. The small CPU time savings are not worth the risk when you're
>     about to run potentially malicious code.
>   * only allow those functions that you /know/ are safe and useful for your
>     purposes. Anything unnecessary goes. Ideally the code should be
>     commented out in the source code. Stuff in the /debug/ and /os/ modules
>     are candidates for removal, as are any file primitives. Be ruthless, the
>     attackers will be too.

Ignoring the fact that your third point may require customizing the
interpreter, why "ideally" would your second point not be accomplished by
executing the sandboxed code in an appropriate environment with a vanilla
interpreter?  I mean, do you have a specific vulnerability that can be
exploited or just an uneasy feeling that it would be easy to make a mistake
(as I call it, a "superstitious vulnerability")?

Likewise for the first point, providing that you're willing to also disallow
loading of uncompiled source code, which might often be the case in
sandboxed contexts.

It seems to me that there is value in being able to execute both sandboxed
and unsandboxed code with the same interpreter on the same state.

>   * find some way to kill off Lua programs that use an inordinate amount of
>     CPU time or memory. Using a hook in the interpreter to detect runaway
>     programs may not be enough, one can write regular expression matches
>     that for all practical purposes never terminate.
> 
> I'm sure I have not covered everything.
> 
> Gé

-- David