Revision 8 as of 2004-05-07 15:19:01

Clear message

Is there such a thing as "Sandboxed Python"..?

Something where you can run a Python that is limited in what it can do.

You could do all sorts of cool things with a sandboxed Python:

A "Sandboxed Python" would let you permit or forbid modules, limit execution slices, permit or deny network traffic, constrain filesystem access to a particular directory (floated as "/"), etc., etc.,.

You're referring to RestrictedExecution, right?

http://docs.python.org/lib/restricted.html

This was brought up recently by Mitch Kapor at PyCon and noted on his [http://blogs.osafoundation.org/mitch/000559.html#000559" blog].

Also see capabilities as mentioned on:

Prior to Python 2.3, there were two modules, rexec and Bastion which were attempted to provide a sandboxed environment. Unfortunately there were known bugs and work-arounds in these modules, and the introduction of new-style classes in Python 2.3 simply made matters worse. Rather than provide a false sense of security, the modules were removed in Python 2.3.

There are a number of people who are interested in creating a new sandboxing system for Python. Zope provides a system which many believe is secure (please include a link!), but is only permits a very restricted subset of Python.


For my part, I think this is something that the PSF should fund development on so that it happens sooner rather than later. There are enough interested parties, that lends itself to getting government or other grant funding. -- KevinAltis

Having used the rexec stuff years ago (1995-6), I seem to recall that the principles of that module involved restricting the modules available, possibly along with the attributes available from each module, class and object. Is there a concise summary of how such mechanisms could have been subverted/exploited and a description of why they are particularly hard to fix? Or is that what this page is about? -- PaulBoddie

I think it should be what the page is about. The basic problem is that Python's introspection allows several ways to "escape". For instance, code which is passed a file object, f, are given access to that single file, but it ALSO can use "type(f)", or "f.class" to get access to "file" itself, and then use it to open any file. Security experts will tell you that "plugging holes" is generally a poor approach to security because there usually turn out to be additional "holes" you hadn't considered -- true security requires an overall design with security considerations included. Doing this for Python is not impossible, but may prove difficult. On the other hand, I would agree that it is worthwhile. -- MichaelChermside

I also have another idea... I have long thought that much of the issues could be handled by creating a module which would make it easy to run bits of Python code in a separate interpreter, running as a separate process, and sandboxed using OS features. The difficulty would be that such a module would require OS-specific code... but it would have the potential to provide sandboxing that was as reliable as the OS would allow. -- MichaelChermside

Sounds like Parrot, (PythonAndParrot,) to me. -- LionKimbro

How so? -- MichaelChermside

Oh, sorry. No, Parrot doesn't refer to running bits of Python code in a seperate interpreter.

Parrot seems like a good target for running the sandboxed code in. I mean: ".NET" and all. Make it so you can secure the Parrot interpreter, and you're good. If a module requires custom C code links, or whatever, make it so you can close the gates to individual parts of C code, or something. And then make it so you can put various RestrictedExecution thingies on the Python code. -- LionKimbro

Perhaps a better solution with the same approach would be ["Jython"]. Java provides excellent sandboxing capabilities, and ["Jython"] has the distinct advantage that it already exists and works. -- MichaelChermside

Unable to edit the page? See the FrontPage for instructions.