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.

Weaknesses

• 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.