[Python-Dev] Sandboxing Python

Sun Mar 4 04:41:58 CET 2012

On Sat, Mar 3, 2012 at 6:51 PM, Guido van Rossum <guido at python.org> wrote:
> On Sat, Mar 3, 2012 at 6:02 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> On Sat, Mar 3, 2012 at 1:37 PM, Victor Stinner <victor.stinner at gmail.com> wrote:
>>> Hi,
>>>>>> Le 03/03/2012 20:13, Armin Rigo a écrit :
>>>>>>>>> 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.
>>>>>>>>> As described in the README file of pysandbox, pysandbox doesn't protect
>>> against vulnerabilities or bugs in Python.
>>>>>>>>>> As usual, I don't see the point of "challenging" us when we have
>>>> crashers already documented.  Also, it's not like Lib/test/crashers
>>>> contains in detail *all* crashers that exist; some of them are of the
>>>> kind "there is a general issue with xxx, here is an example".
>>>>>>>> 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 :-)
>>>>>>>>> You may be able to exploit crashers, but I don't plan to workaround such
>>> CPython bug in pysandbox.
>>>>>> I'm looking for vulnerabilities in pysandbox, not in CPython.
>>>>>> Victor
>>>> Well ok. But then what's the point of "challenging" people?
>>>> You say "this is secure according to my knowledge" and when armin says
>> "no it's not", you claim this is the wrong kind of security exploit.
>> Segfaults (most of them) can generally be made into arbitrary code
>> execution, hence the pysandbox is not quite secure. Even further,
>> "any" sort of this "security restrictions" where you modify locals
>> globals etc. would be seriously prone to attacks like those segfaults,
>> unless you do something with the VM you're running. This makes it
>> slightly less convincing to argue that the VM requires new features
>> (in this case frozendict) in order to support the kind of program
>> that's broken in the first place.
>>>> Well, I think I'm seriously missing something.
>> Could we put asserts in the places where segfaults may happen? Then
> Victor could say "if you want this to be secure then you must build
> your Python executable with asserts on." IIRC some of the segfaults
> *already* trigger asserts when those are enabled.

It's easy for some cases. Stack exhaustion cases might be
significantly harder although you might pass some compiler-specific
options to defend against that. The problem is a bit that those are
"examples", which mean that they might either touch specific parts of
code or "code that looks like that". A good example of a latter is
chaining of iterators. Any iterators that can be chained can be made
into a stack exhaustion segfault.
I suppose with a bit of effort it might be made significantly harder though.
Cheers,
fijal