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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
