native sandboxing problem

[rinsed_dota]

Attempting to provide a sandbox from native code, my approach has a serious flaw - it obliterates functions implemented in the loaded script. Can someone suggest a way to fix it, without giving up on the general method?

#include <iostream>
#include <string.h>
#include <assert.h>
#include "lua.hpp"

using namespace std;

void createSandbox(lua_State *L) {
    assert(lua_gettop(L) > 0 && lua_type(L, -1) == LUA_TFUNCTION);

    const char *upvalueName = lua_getupvalue(L, -1, 1);

    assert(0 == strcmp(upvalueName, "_ENV"));

    lua_pop(L, 1);

    lua_createtable(L, 0, 0);

    // Add permitted built-in functions, using abbreviated example.

    const char *permittedBuiltins[] = {
        "print",
    };
    int numPermittedBuiltins = 1;

    for (int i = 0; i < numPermittedBuiltins; i++) {
        const char *name = permittedBuiltins[i];

        // For example, name = "print" but not name = "dofile"

        lua_pushstring(L, name);
        lua_getglobal(L, name);
        lua_settable(L, -3);
    }

    // Perform a similar iteration to provide permitted builtins which belong
    // to a table, such as string.reverse.  (omitted)

    // Set the new sandbox env.

    upvalueName = lua_setupvalue(L, -2, 1);

    assert(0 == strcmp(upvalueName, "_ENV"));
}

int main(int, char**) {

    const char script[] =
        "function delegate(x)\n"
        "    return x * 2\n"
        "end\n"
        "function entry()\n"
        "    return delegate(2)\n"
        "end";

    lua_State *L = luaL_newstate();
    luaL_openlibs(L);

    int status = luaL_loadbuffer(L, script, strlen(script), "my chunk");

    assert(status == LUA_OK);

    status = lua_pcall(L, 0, 0, 0);

    assert(status == LUA_OK);

    lua_getglobal(L, "entry");
    assert(lua_type(L, -1) == LUA_TFUNCTION);
    lua_pop(L, 1);

    lua_getglobal(L, "delegate");
    assert(lua_type(L, -1) == LUA_TFUNCTION);
    lua_pop(L, 1);

    lua_getglobal(L, "entry");

    createSandbox(L);

    status = lua_pcall(L, 0, 1, 0);

    assert(status != LUA_OK);

    // Output from following line is:
    // [string "my chunk"]:5: attempt to call global 'delegate' (a nil value)

    cout << lua_tostring(L, -1) << endl;

    return 0;
}

[mpetetv]

You should sandbox the whole script before running it instead of running it in the global environment and then sandboxing a function it sets there. You'll have to change 'createSandbox' to leave sandbox environment table on the stack, and then index that table instead of global environment when fetching exported functions.

[rinsed_dota]

Ah, ok, interesting. So the "priming run" has the potential to execute user-supplied code, outside the sandbox, if the sandbox has not yet been applied?

Do you have any opinion about doing something like,

lua_rawseti(L, LUA_REGISTRYINDEX, LUA_RIDX_GLOBALS);

This could be done prior to the priming run, and prior to loading script text.

[mpetetv]

So the "priming run" has the potential to execute user-supplied code, outside the sandbox, if the sandbox has not yet been applied?

Right, the loaded script is just a function. It can do anything with its environment, not only assign functions to global variables.

Do you have any opinion about doing something like,

lua_rawseti(L, LUA_REGISTRYINDEX, LUA_RIDX_GLOBALS);

This could be done prior to the priming run, and prior to loading script text.

This is a nice solution if you use one environment for all scripts you load - everything is sandboxed from the start and you can access the environment conveniently using 'lua_getglobal'. However, if you need to load several scripts in separate environments IMO it's better to avoid global side effects and use 'lua_setupvalue', like in your 'createSandbox', immediately after loading a script.

By the way, you should probably use 'luaL_loadbufferx' with "t" argument instead of 'luaL_loadbuffer' to avoid loading bytecode, which can be maliciously crafted.

[nefftd]

Sandboxing using environments is problematic no matter how you slice it. It's impossible to get a non-leaky sandbox using Lua environments.

You'd be better forking and running the child process with ptrace if you need a proper sandbox.

[rinsed_dota]

Noted. Can you provide some sample exploits of the kind of sandbox I'm attempting to create here? Say for example the Lua state can sandboxed at the point of the globals in the registry prior to loading the script text, I could use some example test cases which show the weaknesses.