Strengths offered by sandbox
- Strong insulator, there's no way, in principle, the box could modify the host's environment.
- Transparency. The Lua script can't differentiate if it's running in a sandbox or not. Besides, with exception of C libraries that they can be unavailable inside a sandbox, it is not necessary to carry through adaptations of code to execute inside of a sandbox.
- Simple, flexible and powerfull interface.
Strengths directly offered by Moon
- Like GCC, the Lua parser is protected against syntax over nesting (e.g. "(((((((...").
- Unlike other interpreted languages, Lua is stackless and protect the C stack (or process stack), then is impossible to make a stack overflow in the process, only in script.
- There's no way to limit the amount of consumed memory.
- There's no way to limit the amount of processor use.
- There's no way to limit the size of the files created/writen.
- There's no way to limit the access over filesystem branches.
- Although all Lua libraries can be executed inside a sandbox, this should be done in a careful way, as some libraries can make sandbox vulnerable.
- The function os.exit available in sandbox does not ends the process, but the execution of the code in sandbox. The execution returns to sandbox's owner lua_State.
- Beyond the methods stdin and env of sandbox, there's no way to pass parameters for a sandbox. And the reading of the results is limited to sandbox's stdout and stderr.
- The function loadlib isn't available by security reasons.
- os.exit of box is currently supported inside of sandbox. However, if a C package is opened inside a sandbox, other than the sandbox itself, that uses a C lua_pcall, the same effect ins't produced. A more robust and general solution with corrotine is being evaluated, but there's still an opened point in this new solution: the management of os.exit in nested sandboxs, which is handled correctly by the current solution.