Re: Lua [in]security and the distributors

[Jonas Thiem <jonasthiem@...>]

I am purely referring to script-level sandboxing, and there this one
year old unfixed issue is kind of a problem. Although it appears the Lua
devs don't really share this sentiment.. oh well.

But how am I supposed to sandbox on a script level if all Lua versions
shipped by common distributions don't have basic patches applied? Ship
my sandboxing application with its own Lua then? I was recently advised
not to do that, since it isn't me as an application dev who should worry
about installing Lua hardened. But it appears nobody else worries
either, so who does in the end? Noone?

I don't think the sarcastic remarks are helpful either. (referring to
someone else here obviously)

On 08/27/2014 11:01 PM, William Ahern wrote:
> 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.
>