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

[Luiz Henrique de Figueiredo <lhf@...>]

[listproc choked on this one too. --lhf]

>From: Bennett Todd <bet@rahul.net>
>To: steve@egroups.net
>Cc: Multiple recipients of list <lua-l@tecgraf.puc-rio.br>

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:-).

-Bennett