Re: Modify Lua interpreter to implement a sandbox script language

[Brice André <brice@...>]

Thanks for your answer.

Andrew> How do you define "harmful" for your environment? And what features do
Andrew> you want sandboxed code to be able to use?

I want to prevent the script from reading or modifying something on the computer it is running. So, no access to file system, no access to sockets, etc. I am not interested in preventing denial of service. So 100% CPU usage, memory exhaution, etc. is not a real issue for me.

The script must be able to perform basic language stuff (assigning/reading variables, structure control (if-then-else, loops, etc.), string manipulation, etc. It will retrieve its inputs and provide its outputs from dedicated functions written in another language and explicitly provided to the script (C functions registered by lua_register).

Andrew> Some of the base functions are essentially part of the language -
Andrew> especially select(), pairs(), ipairs(), type(), pcall(), error(),
Andrew> assert(), tonumber(), tostring(). Without at least those, writing any
Andrew> nontrivial code will be hard.

I agree with you. My idea was first to remove everything, test it, and re-enable non-harmfull functions after. As I was struggling on print function, I tought there was a big issue in my approach.

By the way, I found why 'print' is still available (and why this is the only function of base library that is available). I embed this modified lua engine in an existing library (php-lua) that I did not write myself. After some checks, I realised that this library is exporting its own print function at init, and this is this function that is available (and not the one in lua base library..).

So, in conclusion, I think I will keep the patched version of lua engine because I am more confident with that. But, in addition, I will also put in place your suggestion of using a separate environment, just as a second countermeasure in case of...

If you see anything else that I missed, do not hesitate to comment.

Thanks for your help,

Brice

2018-09-03 22:03 GMT+02:00 Andrew Gierth <andrew@tao11.riddles.org.uk>:

>>>>> "Brice" == Brice André <brice@famille-andre.be> writes:

 Brice> Dear all,

 Brice> I am trying to embed Lua for a sandbox scripting language, where
 Brice> all potentially harmful functions would be deactivated.

How do you define "harmful" for your environment? And what features do
you want sandboxed code to be able to use?

 Brice> To do so, I patched the file "linit.c"

You shouldn't do it that way as a general rule.

There are a few different approaches: you can simply not use
luaL_openlibs() at all; or you can remove the unwanted libraries before
calling any untrusted code; or you can use a separate environment table
for untrusted code and populate it by copying only the functions and
(copies of) library tables you want to allow. (This last method is the
most flexible but probably also the most work to do.)

 Brice> As a result, functions like 'io.open' are no more available. But
 Brice> I am a little puzzled because some functiosn declared in
 Brice> "luaopen_base", like "print" function, are still available.

That suggests that you called luaopen_base yourself from somewhere.

Some of the base functions are essentially part of the language -
especially select(), pairs(), ipairs(), type(), pcall(), error(),
assert(), tonumber(), tostring(). Without at least those, writing any
nontrivial code will be hard.

--
Andrew.