Re: Making LUA safe to execute untrusted scripts [replay]

[steve@...]

Bennett Todd wrote:
> Luc Van den Borre:
> > I'm interested in mobile code - (LUA) code received by an
> > application from an external, perhaps untrusted source.
> 
> A very, very tough problem.

Do you have details on what parts are tough besides the ones mentioned
below?

> > - restrictions on file-access
> > - doesn't crash - or at least crashes nicely without taking down
> >   the host program

These are easy - just modify thr file access functions and use the
lua error hooks to catch errors. 

> > - cpu usage limitations (which would probably mean pre-emptive
> >   multitasking between scripts)
> > - memory limitations (no more than a fixed amount of memory to
> >   play with)
> > - time limitations (run no longer than fixed amount of cycles or
> >   get killed)

These would be nice, but it's not clear to me that they are necessary.
They also cause issues when good programs that people want to use these
resources need them.

> 
> Noble goals, and nicely specified. A couple more to add:
> 
>   - restrictions on memory access within the program (can't read or
>     write arbitrary locations in memory within the process)

Lua already does this, right?

>   - restrictions on other syscalls --- e.g. connect, kill, ...

This is easy to implement.

> I've no idea whether Lua is well-suited to applying such
> restrictions, but I'll say this: if its designers felt that it was,
> I'd be a _lot_ liklier to trust it in a role like this than any
> competitor I've seen, including most especially Java and Javascript.
> 
> Simplicity is a virtue. Doubly so when security is a goal.

Agreed.

Steve