lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Hi David,

You understood some of my problems: safety (don't destruct the machine) and eliminating unwanted function access.

I will reread all this thread and make a sumary later today. Many interesting point are in here.

thanks everybody,
Alain

David Given escreveu:
On Tuesday 23 August 2005 09:30, many people wrote:

Lots of messages about sandboxing Lua


Wee! 40 messages waiting for me when I get in to work!

The reason why I'm posting this is that I've noticed that nobody's actually explained the following yet, which may help to clarify things slightly.

There are two parts to Lua; there's the language (if...then...end, while...end, function...end, etc), and there are the libraries (print, math.sin, io.open, etc). The Lua *language* has zero functionality for doing anything without the libraries. As all the libraries are accessed via global variables, and the set of global variables a piece of code has access to can be easily changed, this means that the set of available libraries is trivially customisable. This means that it's possible to remove *all* ways that a Lua script can interact with the outside world, by simply removing the set of available libraries.

This Lua program:

  script = io.read("*all")   -- read in text from stdin
  chunk = loadstring(script) -- compile into an executable Lua chunk
  setfenv(chunk, {})         -- completely empty the chunk's globals

  status, result = pcall(chunk) -- execute the chunk
  print("status=", status, " result=", result)

...implements a safe Lua interpreter. It will execute the Lua program given in stdin in a sandboxed environment; the only way the sandboxed program has of interacting with the outside world is to return a value --- try it. If you can break it, the devs here would love to know because it's a major bug. It'll even execute invalid Lua code safely, returning the error that occurred so your program can deal with it.

(Typically you wouldn't do the above, because there are a number of safe functions that all Lua programs use; tonumber(), tostring(), type(), unpack(), math, table, etc. You'd want to provide these to the sandboxed program.)

This *doesn't* put limits on CPU time and memory usage, but you can do that fairly easily by using the C API --- you'd set a timer that, when fired, would cause the sandboxed program to be terminated. By putting a bound on the amount of CPU time you automatically put a bound on the amount of memory, but that can be customised as well.

Does this help?