Replacement for rexec/Bastion?

[Michael Chermside]

Colin Coghill (SFive) writes:
> Hi, a year or so back some students of mine and I wrote some software 
> which made use of the rexec module to run untrusted user code relatively 
> safely.
   [...]
> I noticed that rexec and Bastion have been
> withdrawn for (in)security reasons.

Yes. Of course, you can still go back and get the old versions of these
and run them. It won't be any safer than it was before they were
withdrawn, but it will be just as useful (or not useful) as it was
when you used it a year back.

> Is Python (preferably CPython 2.3) still able to "sandbox" bits of code
> under an application provided API safely?

No. There are some levels of safety that CAN be achieved, but there's
no real way to reliably limit resources. That's why rexec and Bastion
were withdrawn rather than being improved... there was no working
replacement available or even on the horizon. Zope's RestrictedPython
is the closest thing there is... a quick summary of its approach was
posted to python-dev today: 
http://mail.python.org/pipermail/python-dev/2003-August/037791.html

> I can trap endless loops and the like, 
> but I need something to stop them just importing sys and raising havoc.

Sorry to be so blunt here, but no, you CAN'T trap endless loops and
the like. If you think that you can, then you don't really understand
what's involved in securing untrusted code. Consider, for instance,
this code:

     x = 1000000**1000000

I guarantee it'll lock up your python interpreter for a fairly long
time. And it executes in C so there's no possible way you can trap
it. That's not all, I can do things like this:

     x = [1] * sys.maxint

So I have to question whether you really know what you want here.
The truth is, 98.4% of all people who claim to need to sandbox
code could get by just fine with no restrictions at all. (Gee, isn't
it fun to just make up spuriously-accurate statistics?) If you're
one of the remaining 1.6%, you need to decide whether you just need
to prevent malicious code from accessing services (eg: reading /
writing files), or if you ALSO need to prevent it from bringing
down the program that's running it. If just closing off services
is good enough, try the old rexec/Bastion or check out 
RestrictedPython, but realize that neither is perfect (RestrictedPython
is better). If you actually need to prevent DOS attacks, then the
only approach that could work would be to launch the untrusted
code in a separate process, and allow the OS to limit that processes
access to services (like the filesystem) and resources (memory and
cpu-time constraints).

-- Michael Chermside