lua-users home
lua-l archive

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


On Wed, Aug 3, 2011 at 6:10 PM, Mateusz Czaplinski <czapkofan@gmail.com> wrote:
> On Wed, Aug 3, 2011 at 2:53 AM, Josh Simmons <simmons.44@gmail.com> wrote:
>> On Wed, Aug 3, 2011 at 4:30 AM, Stefan Reich
>> <stefan.reich.maker.of.eye@googlemail.com> wrote:
>>> Here's the project homepage: http://safelua.sf.net
>>
>> I'm not super sure what exactly you're going for here, Lua already is
>> very easy to sandbox completely
>
> 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.
>
>> the issue is providing "safe" APIs
>> that provide enough power to be useful.
>
> What about infinite loops and eating all memory?
>
>> 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.
>
> 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>
>
> /M.
>
>

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.