Re: Reducing Lua's Trusted Computing Base

[Quae Quack <quae@...>]

On 28 July 2010 08:15, Dimitri DeFigueiredo <dimitridobrasil@gmail.com> wrote:
> Hey Folks,
>
> I think Lua's small size give it a significant advantage over other
> languages when it comes to security. It is also (likely deceptively) easy to
> setup a sandbox to run untrusted code in Lua. In my mind, this makes Lua a
> very strong candidate for implementing server-side software. This is
> especially true when multiple users collaborate using their own automated
> scripts in the server as in massive multi-player online games or trading
> platforms.
>
> The only shortcoming I see is that Lua's VM (as described in
> http://luaforge.net/docman/view.php/83/98/ANoFrillsIntroToLua51VMInstructions.pdf)
> was not designed to run malicious code.
> For example, what happens when a "malicious" chunk specifies an invalid
> opcode? Does the VM halt or just ignore it?
>
> Therefore, when I want to sandbox code using Lua, I must trust not only the
> VM but also the "compiler" (lexer, parser,etc). There's a lot of extra C
> code outside the VM that also needs to be trusted.
>
> To be sure I can sandbox malicious code with Lua, I need to verify the
> platform. It is much easier to just verify the C code in the VM than in all
> of Lua. Is there a way to reduce the size of Lua's "trusted computing base"
> to the VM only? Is this at all in the roadmap? I understand that the
> internals of the Lua VM still change significantly at each release.
>
>
> Thanks!
>
>
> Dimitri
>

To rephrase:
You just have all code as Lua source, not byte code. Don't put load*
functions that accept bytecode in the sandbox (currently if you want
loadstring in the sandbox, you'll have to ensure that the first byte
isn't \23; in lua 5.2 there is an argument that lets you specify if
you wish bytecode to be allowed to be loaded).

Daurn