Replacement for rexec/Bastion?

[Colin Coghill (SFive)]

In article <mailman.1061917732.11442.python-list at python.org>, 
Michael Chermside wrote:
> 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.

Fortunately the project back then was just a prototype so no-one
ever relied on it anyway. That particular one's since been rewritten
in Java (boo, hiss!) because its security manager stuff was more appropriate
for the task. (It was a "safe environment for running interactive email 
attachments")

>> Is Python (preferably CPython 2.3) still able to "sandbox" bits of code
>> under an application provided API safely?
> 
> 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


Thanks, that looks interesting. I had seen mention of it but hadn't 
realised it wasn't just rexec behind the scenes.


>> I can trap endless loops and the like, 
>> but I need something to stop them just importing sys and raising havoc.
> 
> 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

I think I resolved this kind of thing a while ago by using seperate 
processes. The user-code one and the actual application. If the 
user-code one stops responding for some tunable time, it gets 
kill -KILL'ed and restarted from the last checkpoint minus the 
offending code.
And for resource limits, ulimit seems to work fine on the several
systems I've tried.

Yes, this is messy UNIXy stuff, and loses portability, which is bad, 
but it at least seems to make it possible to do this stuff.

> So I have to question whether you really know what you want here.

Yeah, I'm pretty sure. 

I'm looking at making a system that allows bits of code from many 
sources to be sent to various systems across the network and executed on
that system.

eg. A shared robot that goes out of network range to take some
measurements. You want people to be able to send it some code
to control it and collect appropriate readings while it's out
of range. And, of course, robots are often expensive so you
want it to be fairly secure :)

I know I can do it in Java, but I don't like programming in Java,
and I do like programming in Python :)

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

Oh. See above :)

- Colin