Sandboxing [Was Re: killing thread ?]

Terry Reedy tjreedy at udel.edu
Fri Jan 24 18:21:09 EST 2003


"Jack Diederich" <jack at performancedrivers.com> wrote in message
news:mailman.1043432149.5693.python-list at python.org...
> On Fri, Jan 24, 2003 at 12:44:24PM -0500, Jp Calderone wrote:
> > On Fri, Jan 24, 2003 at 07:52:08AM -0800, Paul Rubin wrote:
> > > Peter Hansen <peter at engcorp.com> writes:
> > > > If you're worried about some kind of denial of service type
> > > > thing with code written by someone else: you're out of luck.
> > > > Don't use Python.  (Or, better yet, get over the worry and
just
> > > > accept this possibility.)
> > >
> > > Wha?  Python provides the rexec and bastion modules specifically
to
> > > have a way to run hostile code in a sandbox.  So what kind of
advice
> > > is "don't use Python"?  If sandboxed code can be prevented from
> > > accessing sensitive data or doing i/o, but can't be prevented
from
> > > looping unkillably, that's a bug in Python.
> >
> >   Yes, that's why Python provides them.  But this misconception
(that they
> > work) is also why it will soon -not- provide them :P  And neither
RExec nor
> > Bastion ever protected you against "while 1: pass"

Hmmm.  Disable 'while': force use of for loops, and limit list
lengths, and recursion depth and ....

>> or "100L ** 100L ** 100L  ** 100L ** 100L".

Hmmm. Remove longs.  But then language is not quite Python.

> If you've ever worked on an LPC MUD or thought about implementing
one
> you have to deal with giving 'untrusted' users code-level access to
the system.

I have sometimes thought I would like to play (or write) a game
user-scriptable in Python.  But I keep seeing problems like the above.
Removing parts of the language, to make it *not* Turing-complete, as
well as some builtin functions, is only thing I can think of.

Terry






More information about the Python-list mailing list