I never did that actually and it seems involved, hard and very limiting for what such a script could do. I dislike talking about touchy high risk stuff like th

I never did that actually and it seems involved, hard and very limiting for what such a script could do. I dislike talking about touchy high risk stuff like that in general since someone might think what I say is a list of things to do to be 100% secure and get burned. What it says on [0] is a good start I guess: only textual code input, no bytecode (5.1 has bytecode verification but it was removed in 5.2 because it had flaws and gave false sense of security, there were examples of breaking stuff up with malicious handcrafted bytecode), white listing. To not allow something (like os or debug libs) to be used just don't include it in the environment for that used supplied function (it does restrict you quite a bit though I guess...). For memory you could use your own allocator and enforce a limit there (and probably set your own atpanic function in 5.1 and longjmp out of it because you might kill the entire program with the default one when Lua won't be able to alloc the error message itself, in 5.2 and 5.3 it's preallocated in the VM so that won't happen). To prevent runaway Lua loops you can use the count debug hook and throw a Lua error in it, pcall will get that (just remember to reset it between calls because it doesn't reset to 0 on its own). Preventing runaway C loops is up to making sure you don't expose something that can get stuck. You could also set count to something low or use line debug hook and check the time in it and error out if the code took too long already but it might slow the code down too badly (depends on what you do I guess). That stuff (mem alloc, debug hooks, panic, environments, etc.) is in the docs. Long strings can also DoS the hashing algorithm and that might totally kill performance with tables, it's a trivial change to fix that yourself or use one of the patches[1]. It came up on the mailing list too. I'm sure it happens on 5.1, not sure about latest 5.2 and 5.3 right now and I don't have time to look into it. LuaJIT doesn't also let you set the allocator on 64 bit and has some other issues with out of memory errors[2] (I don't know what they are exactly about). I guess it's out of the question if you're really paranoid (stock Lua 5.1 is also way easier to read, modify and compile IMO). I'm not very familiar with LuaJIT. [0] - http://lua-users.org/wiki/SandBoxes http://lua-users.org/wiki/SandBoxes [1] - http://lua-users.org/wiki/HashDos http://lua-users.org/wiki/HashDos [2] - http://luajit.org/status.html http://luajit.org/status.html