[Python-Dev] Python jails

[Victor Stinner]

Le 11/06/2011 02:41, R. David Murray a écrit :
> I haven't read through your post, but if you don't know about it I
> suspect that you will be interested in the following:
>
>      http://code.activestate.com/pypm/pysandbox/
>
> I'm pretty sure Victor will be happy to have someone else interested in
> this topic.
>    
Yes, I am happy :-) The project URL is https://github.com/haypo/pysandbox/

Activestate page is wrong: pysanbox does support Python 3 (Python 2.5 - 
3.3).

pysandbox uses different policy depending on the problem. For example, 
whitelist for builtins, blacklist for object attributes. pysandbox is 
based on Tav's ideas.

The main idea of pysandbox is to execute untrusted in a new empty 
namespace, the untrusted namespace. Objects imported into this namespace 
are imported as proxies to get a read-only view of the Python namespace. 
Importing modules is protected by a whitelist (modules and symbols 
names). To protect the namespace, some introspection attributes are 
hidden like __subclasses__ or __self__. Performances are supposed to be 
close to a classic Python interpreter (I didn't run a benchmark, I don't 
really care).

An empty namespace is not enough to protect Python: pysandbox denies the 
execution of arbitrary bytecode, write files, write to stdout/stderr, 
exit Python, etc. Tav's sandbox is good to deny everything, whereas you 
can configure pysandbox to enable some features (e.g. exit Python, 
useful for an interpreter).

About restricted mode: you can also configure pysandbox to use it, but 
the restricted mode is too much restrictive: you cannot open files, 
whereas pysandbox allows to read files in a whitelist (e.g. useful to 
display a backtrace).

If you would like to implement your own sandbox: great! You should try 
pysandbox test suite, I'm proud of it :-)

I am still not sure that pysandbox approach is the good one: if you find 
a vulnerability to escape pysandbox "jail" (see pysandbox Changelog, it 
would not be the first time), you can do anything. PyPy sandbox and 
"Seccomp nurse" (specific to Linux?) use two processes: the Python 
process cannot do anything, it relies completly in a trusted process 
which control all operations. I don't understand exactly how it is 
different: a vulnerability in the trusted process gives also full 
control, but it's maybe a safer approach. Or the difference is maybe 
that the implementation is simpler (less code?) and so safer (less code 
usually means less bugs).

"Seccomp nurse":
http://chdir.org/~nico/seccomp-nurse/

I tested recently AppEngine sandbox (testable online via 
http://shell.appspot.com/): it is secure *and* powerful, quite all 
modules are allowed (except not ctypes, as expected). AppEngine is not a 
Python sandbox: it's a sandbox between the Python process and Linux 
kernel, so it protects also modules written in C (pysandbox is unable to 
protect these modules). AppEngine modifies the Python standard library 
to cooperate with the low-level sandbox, e.g. raise nice error messages 
with open(filename, "w"): invalid file mode (instead of an ugly OSError 
with a cryptic message).

Get more information about pysandbox and other sandboxes in pysandbox 
README file.

Victor