sandboxing python code

[ben at transversal.com]

Moshe Zadka <m at moshez.org> wrote in message news:<mailman.1054632844.16009.python-list at python.org>...
> On 3 Jun 2003, ben at transversal.com (ben at transversal.com) wrote:
> 
> > I've recently (6 months or so) been converted to Python, and so have
> > become an avid reader of this newgroup. One thing that has been brought up
> > occasionally by other people, but never has really been answered
> > satisfactorily is the problem of running untrusted code.
> 
> How is the answer "you can't" not satisfactory?
> 
> I'll note that even in Java, where a lot of energies and quite a lot
> programming hours has been spent on this kind of stuff, it would be hard
> to accomplish. IIRC, Java's sandboxing had quite a few bugs itself, and
> moreover has limited protection against allocating too much memory (you
> can tell the JVM not to let the process allocate over a certain amount,
> but not, AFAIK, by sandbox) and against CPU-intensive DoS attacks -- and
> that's the best technology.
> 
> My suggestion is to try to find a way where you can handle the overhead
> for separating the tasks into separate processes, and then use your OS's
> sandboxing capabilities. This easily lets you take care of such things
> as CPU and memory limitations, and with more advanced operating systems
> (like FreeBSD's jails, NSA's SELinux and chroot()) you can achieve more
> control. As an extreme measure, you may consider something like
> User-Mode-Linux, which gives you (relatively) cheap virtualization of
> the operating system.
> 
> Of course, you can still use the fact that it is Python on both sides
> of the fence by using remote-object protocols to communicate -- such
> as Pyro or Twisted's Perspective Broker.
> 
> Just like in real life -- if you don't trust someone, don't invite them
> into your house and try to keep an eye on them, it's just too hard. Communicate
> with them by phone, so that their opportunity to harm you is limited. Of
> course, they may shout into your phone, or try to overload your stack
> by sending you malformed objects. But it is is much easier to defend against 
> these kind of attacks.
> 
> Yes, Java and Flash are treated as "code you can run untrusted", but this
> is just wrong. It's fairly easy, for example, to crash most browsers with
> these, which is a fairly efficient DoS attack :)

Thanks for all the replies. I will have to have a think about it.
At the moment I am experimenting using twisted to both control the
lifetime of sub processes and to communicate with them. This way I can
use chroot and resource.setrlimit to hopefully isolate the bogus code

Thanks again

Ben
---