Separate the sandbox from the LuaC

[numberZero]

Actually a separate sandbox implementation exists already, even in 2 variants:

• My variant
• Hawk777’s variant

Does any of them suit the needs of the LuaC well enough? @sfan5 @Jeija We had discussion on the API with @Hawk777 but haven’t decided which one is better.

[numberZero]

I started working on a true sandbox, implemented as Lua module. It will provide strict time and memory limiting. But the code will be executed in a completely separate Lua state.

The project will be at https://gitlab.com/numzero/libluabox

[ghost]

I see some problems with this:

1. It needs to support all OSs.
2. Unless it's integrated as part of Minetest core, it will require an external module as a dependency. That reduces the amount of public who will use it, and introduces an attack vector for third party providers of the mod if it's distributed in binary form (there was a scandal in Second Life back in 2010 regarding something very similar, where a binary was abused by a third party viewer for nefarious purposes).
3. The LuaC mod needs to be granted insecure execution (in mod_security) in order to use require() (edit: again, unless it's integrated as part of the core and included there).

And I have a question. If it's a separate environment, how would the main Lua code access inputs and outputs of the LuaC sandbox? Do you have a proof of concept of integrating this sandbox into the LuaC code?

[numberZero]

1. It needs to support all OSs.

2. Unless it's integrated as part of Minetest core, it will require an external module as a dependency. That reduces the amount of public who will use it

That’s a problem, I have Linux only, not even a BSD. But a fallback Lua-only solution (similar to that in Mesecons) will always be supplied (see GL#6).

and introduces an attack vector for third party providers of the mod if it's distributed in binary form

People that download unknown binaries are always at risk. And don’t forget that even a regular mod may do all the nasty stuff like writing to your .bashrc, with all the consequences (that probably requires insecure environment nowadays, but...).

3. The LuaC mod needs to be granted insecure execution (in mod_security) in order to use |require()|.

Not the LuaC mod, but the separate sandbox mod (GL#7). The difference is that, you don’t need to trust each and every mod needing the sandbox, but just the sandbox itself. And if you don’t trust even that, a (less reliable) fallback solution will be available nevertheless.

And I have a question. If it's a separate environment, how would the main Lua code access inputs and outputs of the LuaC sandbox?

There is a special API for that. Right now, it lets you to pass arbitrary code (as a list of strings) into the sandbox, and gives you its return values (again, strings only).

Do you have a proof of concept of integrating this sandbox into the LuaC code?

Not into LuaC yet, that will need some time, but it works. Currently (the API is to be changed), require returns single function; the arguments are:

• Time limit (number, seconds),
• Memory limit (integer, kilobytes)
• Code (one or more string, effectively concatenated) and the return values are:
• Success (boolean)
• Results (one or more string) or error message (string) The function may error if the host Lua can’t allocate memory, or if arguments are invalid (i.e. of wrong type, or out of range).