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

["Nick Trout" <nick@...>]

> 2000-04-17-21:49:55 steve@egroups.net:
> > Bennett Todd:
> > > 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?
>
> Details, no. Generalities, well, I'll try and blither on a little
> longer:-).
>
> There've been quite a few efforts, in different contexts, to create
> safe mobile code. The currently fashionable cases include Java
> and Javascript. An older example would be using Postscript for
> a portable document format. I can't recall a single effort that
> has succeeded, in the sense of resisting even moderate efforts to
> thwart it. Postscript has come the closest; by disabling all I/O
> operations, and not having anything else in the process memory space
> to worry about, and not worrying if the thing slams against process
> limits and dies, previewers are hard enough to hack that people
> haven't bothered recently; and printers aren't interesting to hack.
>
> But when you want the mobile code to be able to interact with other
> parts of the process space, and with the rest of the system, in a
> restricted, controlled fashion, then you have to come up with a way
> to specify the restrictions and controls. And the way you specify
> it has to be simple enough to make it possible to understand and
> modify the specification. And it has to be simple enough to
> implement so the implementation is free of exploitable bugs.
>
> So far that collection of simplicity hasn't been assembled. But
> then, there hasn't been a programming language architect in decades
> who delivered simplicity like Lua's simplicity. And Lua's a _lot_
> prettier than Forth:-).

What about Python? Its simpler and more powerful than Lua. It has proper classes
and no confusing upvalues or tags. Lua is faster and more compact though. Better
for games!

I think if you set up a state for each object "thread" and altered Lua's memory
manager (I think you'll only have to modify one function luaM_realloc for all
allocation.) then you could establish a fairly solid system. Its easy to limit
the amount of system level access the user would have and memory management
could be restricted and monitored using your modified allocation system. I'd be
tempted to do something like automatic persistant states for objects then the
user doesnt need (writeable) file access. eg. any information could be stored
using something akin to the registry or .ini files. Or each object could have a
VM space which is initialised on creation and serialised, retaining its state?

It would be really nice if there was a version of Lua that you could just give
some memory (including the state info) and all allocation was done through this
and all code was generated in this. You could serialise a whole frozen Lua
state? Great for memory limited systems (and you could monitor illegal memory
access more easily). Maybe it exists already and I havent read the docs!

N