Make impossible to access operating system from Lua scripts

For security reasons, Lua scripts should not be able to read files or
run programs on the host computer; freeciv scenarios should only be
able to influence the state of the game, not the state of the server
process or computer (except through normal scenario events, such as
end of game).

For this reason, we do not load some standard lua libraries that allow
access to files or the operating system. We also disallow loading lua
libraries so that the script cannot go around this restriction.

This is the 2.2 and trunk version (Lua 5.1): we exclude the io
library, os library, package library, and blacklist functions dofile,
loadfile.

For Lua 5.1, the list of modules and functions we consider unsafe are:

"os",
"io",
"package",
"dofile",
"loadfile",
"module",
"require"

These are all unavailable by not being loaded or being explicitly blocked.

See gna bug #15624

(Browse SVN revision 17158)

A very similar version, but in "pure C". The 2.2+trunk version of the patch has an added compiler warning if the unsafe functions information is not updated for a new Lua version. The 2.1 patch does not have this, since Lua 5.0 doesn't define a numeric version symbol.

Ideally, our lua script runtime should be configured in lua. Two reasons for pure C:

1. It's what freeciv coders understand.
2. Tolua is regrettably not so conductive for doing this since, among other things, errors (explicit by asserts or unintentional ones too) are silently ignored in embedded code in api.pkg.

(file #8638, file #8639)

This solution is easy and less complex/less lines of code, which makes it easy to choose. This solution is also very easily applied to the 2.1 branch. (Less code than in 2.2 or later due to how Lua 5.1 removed the public functions to load libraries one by one).

------

Subject: [PATCH] Make impossible to access operating system from Lua scripts

For security reasons, Lua scripts should not be able to read files or
run programs on the host computer; freeciv scenarios should only be
able to influence the state of the game, not the state of the server
process or computer (except through normal scenario events, such as
end of game).

For this reason, we do not load some standard lua libraries that allow
access to files or the operating system. We also disallow loading lua
libraries so that the script cannot go around this restriction.

This is the 2.2 and trunk version (Lua 5.1): we exclude the io
library, os library, and blacklist functions dofile, loadfile.

For Lua 5.1, the list of modules and functions we consider unsafe are:

"os",
"io",
"package",
"dofile",
"loadfile",
"loadlib",
"module",
"require"

These are all unavailable by not being loaded or being explicitly blocked.

(file #8635, file #8636)

Be sure that by saying that security is hard, I don't mean that I can do it better than you -- on the contrary, if we work together, this will be much better. What I meant was: don't trust me yet, it's not so easy.

I agree that the security issue is very important. The caveat is that just because we think it works doesn't mean that it does, security is hard, especially with a runtime that we don't know so well :-)

Luckily, the lua runtime is very small. We can investigate not even loading the os and io libraries, however that adds more code (and can only be done with lua calls, not C calls in 5.1?).

What is important now is that all script code is executed inside our setfenv environment, and that none of the remaining functions can give the script access to the outside global environment (like getfenv, load, require, module etc could do).

I have not investigated if there are any holes in tolua. The tolua module (providing tolua.type that we need inside the restricted environment) has also not been investigated.

Notice that we may replace all modules (string, table, math, coroutine (should it be included?) and tolua) by tables that contain just the functions we want, if we need to block out any of them.

Ok, no not really. Feel free to work on this. I will type up documentation later. What will happen to 2.1? It looks like it is still using Lua 5.0 while 2.2 is using 5.1.

Can I assign this bug to me?

Code executed in our Lua runtime has by default access to all builtin
lua functions and modules. These include functions to load lua files
or access the operating system.

As an example, a ruleset or scenario script could execute arbitrary
shell scripts (for example the 'uptime' program to use a harmless
example) using: os.execute("uptime"). Additionally the builtin module
io allows lua code to open and read/write files.

If we can, we should make freeciv rock-solid safe w.r.t scenario
scripts, they should be simple data, without security implications.
Otherwise a server administrator must scrutinize any custom ruleset
and scenarios before installing them. And users could experience
viruses in the form of freeciv scenarios or savegames.

Lua provides a method called "setfenv" that allows the caller to set
the environment a called function executes in. We set up a restricted
environment and execute ruleset/scenario code only inside this. In the
code, this restricted execution is carried out inside
script.c:script_call (which is now the only entry point for user
code).

The setup of the restricted environment uses a whitelist of builtin
symbols (functions, values and modules) that we allow in the scripting
environment, defined in api.pkg, where we also have a comment:

We want to assure that
1) The script has no access to the operating system
(loadfile, os module, io module).
2) The script can not modify modules that freeciv's script runtime
uses, for example by diverting error handling routines or similar.
3) The script can not break out of the sandbox.

I have used this community resource as reference when picking builtins
to whitelist:

http://lua-users.org/wiki/SandBoxes

Notice however that a normal freeciv script needs next to no builtins.
We don't forsee needing class and inheritance programming, so much of
lua's power can be turned off. The whitelist of builtins is thus
small.

The sandbox construction assumes that all parts of our game api are
safe.