Re: [ANN] New project: Safe Lua

[Stefan Reich <stefan.reich.maker.of.eye@...>]

>>> I'm not super sure what exactly you're going for here, Lua already is
>>> very easy to sandbox completely

Yes. That's why I use Lua. The point is in running EVERYTHING in an
array of communicating sandboxes, which enables new kinds of
applications. I guess you'll understand the idea a lot better when
there are some non-trivial examples.

>> Umm... I'm not so sure about it... when I look at
>> http://lua-users.org/wiki/SandBoxes and the amount of question marks
>> and "not guaranteed" disclaimers on the page.
>> Among others, bytecode is a known non-obvious vector of attack.

Huh? Bytecode will be disallowed in my system as there is no bytecode
verifier for Lua yet. In fact, I just implemented that check (a simple
test for the first byte of the file) and it will be in the next
release.

>> What about infinite loops and eating all memory?

Will all be protected against. Infinite loops I have taken care of
already through a debug hook. It's also gonna be in the next release.
Memory can be handled similarly. In the worst case, we'll patch the
interpreter and add a check in the allocator. Any more questions? :)

>>
>>> If these kind of things are your goals then existing projects already
>>> provide similar but more powerful control over these issues, things
>>> like Linux cgroups and Chrome's NaCL.

Ah. OK! I'll look into those technologies and see if they bear any
relation to my vision. I kinda doubt it, but... well, you never know.
:)

>> Yeah, initially I thought the OP was doing some interesting scientific
>> research and wanted to publish it, but then I realized it's a project
>> claiming a lot ("super-duper extra safe!") but I totally don't trust
>> it. Zero proofs, zero references, no protection against malicious
>> bytecode if I see correctly (thus, absolutely not safe), and author
>> seems to skim over the "making minimal sandbox" step as if it was
>> trivial. <shudders>

Dude. It's the first release to get the word out. All the science you
want is gonna come. Protecting against bytecode is super simple. And
making a minimal sandbox is indeed easy with Lua. Lua is in use in
huge real-world projects and it seems it has proven that it works,
even with untrusted code, so it's a good basis to start with.

If there turn out to be any holes anyway, we'll fix them. This is a
research project, and it is obviously in the academic stage now.
Heavy-duty real-world application comes after that. You should know
that, given that you throw the word 'science' around a lot... :)

Having that out of the way: Have you even gotten a glimpse of the
vision of the whole thing? If not, please refrain from trashing the
project until you understand it. Because there is a vision behind it.
It's not just finger exercise. Thanks.

> Lua is easy to sandbox since you can remove all the unsafe functions
> and/or replace them with ones of your own design. Memory and CPU are
> also reasonably easy to control with help from the OS, or by removing
> unfriendly functions. The easy way to protect against malicious
> byte-code is to disallow it altogether.

Yes! That's what I do here and that's why I chose Lua.

-Stefan