[Python-Dev] Sandboxing Python (original) (raw)
Victor Stinner victor.stinner at gmail.com
Mon Mar 5 23:11:31 CET 2012
- Previous message: [Python-Dev] Sandboxing Python
- Next message: [Python-Dev] Sandboxing Python
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Sandboxing Python
- Next message: [Python-Dev] Sandboxing Python
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]