Re: Lua [in]security and the distributors

[William Ahern <william@...>]

On Wed, Aug 27, 2014 at 06:47:59PM +0200, Jonas Thiem wrote:
> I see two obvious choices:
> 
> 1. You could simply announce Lua is unsuitable for sandboxing. However,
> that would be sad since in practice many use it for that, and they
> probably won't stop doing that.

The term sandboxing is rather ambiguous, and it wasn't clear from your
previous post whether there was any confusion in this regard.

When system engineers talk about a sandbox I think they're most commonly
referring to chroot jails and similar kernel mechanisms which hide resources
from a process. Lua doesn't support this _directly_ because it doesn't have
bindings to Unix-specific system interfaces. (Shameless plug: my Lua Unix
module has chroot; luaposix doesn't because chroot isn't POSIX. OTOH,
luaposix has setrlimit, while I still need to add to Lua Unix.)

But Lua's script-level sandboxing is actually quite robust[1], and its small
set of default interfaces (easily throttled by not loading the io and os
modules), small and simple VM, and general simplicity (IOW, small code
surface area) make it a much better choice for use within system-level
sandboxes than almost any other language I can think of.

It's highly noteworthy that after Peter Cawley published a bytecode exploit
for Lua 5.1, PUC Lua not only amended the Lua 5.2 chunk loading interfaces
to allow rejecting bytecode, but they also ripped out the entire bytecode
verifier, which was a courageous (and IMHO correct) decision. PUC also
grudgingly added a randomized hash function, which was admittedly a tough
call. So they've shown not only the ability to add complex behavior to
accord with widely-held best practices, but that on balance they prefer
simplicity overall in an effort (directly or indirectly) to achieve
correctness and minimize exploitable code surface.


[1] Hackers don't appear to have much trouble breaking out of hardware-level
virtual machines like VMWare, KVM, or Xen; or meticulously designed
environments like the Java JVM. So you can't judge a sandbox merely by what
it theoretically limits. You 1) have to do so by _how_ it limits
privileges--e.g. how complex the logic is and how easy it is to debug. And
2) how easy and convenient it is for the application to limit or expand
privileges. Academically you want fine-grained capabilities a la SELinux,
but then declaration and management of privileges can become error prone.
This is why I like Lua on the one hand, and system-level approaches like
Capsicum on the other.