campadrenalin / hardlupa Goto Github PK

These are methods of lupa.LuaRuntime that we need to replicate over to the safer HardLupa interface. LuaRuntime.require, however, will never be ported for safety reasons, so we don't have to worry about that.

The Python-level sandbox should immediately upon creation revoke all its access to the filesystem and any sensitive modules, in a way that cannot be undone from the inside. Instant permanent permissions drop before a single character of foreign code is processed. That way, if the Lua-level safeguards fail, you still have process-level safety in the sandbox to break out of.

Here's the real safety gold. Write a function globalflush(LuaRuntime x, list names = safe_set, dict values = {}) such that:

• Returns a dict of all preserved globals.
• Deletes any globals that are not preserved from the global namespace.
• Running it with no extra arguments assumes the standard "safe" set of names for globals.
• If values is empty, use the existing values for every global named in names.
• If values is not empty, erase all globals and replace them with the contents of the values dict.

Thus, you can run globalflush once at the start of the runtime with no arguments to collect up all the standard libraries deemed safe (the list is defined as a constant in the hardlupa module), cache the result, and call globalflush with that result at any time to restore the runtime to a fresh state.

There's a definite performance hit running each Runtime in a separate process. Some situations might call for running a pool of runtimes in the sandbox, or in less paranoid situations, running in the same process as the Python logic. Separating the multiprocessing code into a Sandbox class should provide that kind of flexibility, which is essential (at the very least) for the project I'm going to be using this project for (which will create a lot of Runtimes but is injection-risky enough to still warrant process isolation).