Home Original page

[Python-Dev] Sandboxing Python

Victor Stinner victor.stinner at gmail.com
Mon Mar 5 23:11:31 CET 2012 
>>> I challenge anymore to break pysandbox! I would be happy if anyone
>>> breaks it because it would make it more stronger.
>
> I tried to run the files from Lib/test/crashers and --- kind of
> obviously --- I found at least two of them that still segfaults
> execfile.py, sometimes with minor edits and sometimes directly, on
> CPython 2.7.

Most crashers don't crash pysandbox because they use features blocked
by pysandbox, like the gc module. Others fail with a timeout.

3 tests are crashing pysandbox:

 - modify a dict during a dict lookup: I proposed two different fixes
in issue #14205
 - type MRO changed during a type lookup (modify __bases__ during the
lookup): I proposed a fix in issue #14199 (keep a reference to the MRO
during the lookup)
 - stack overflow because of a compiler recursion: we should limit the
depth in the compiler (i didn't write a patch yet)

pysandbox should probably hide __bases__ special attribute, or at
least make it read-only.

> If you are not concerned about segfaults but only real attacks, then
> fine, I will not spend the hours necessary to turn the segfault into a
> real attack :-)

It's possible to fix these crashers. In my experience, Python is very
stable and has few crasher in the core language (e.g. compared to
PHP). But I agree that it would be safer to run the untrusted code in
a subprocess, by design.

Running the code in a subprocess may be an option to provide higher
level of security. Using a subprocess allows to reuse OS protections.

Victor
More information about the Python-Dev mailing list