[Python-Dev] Sandboxing Python

Maciej Fijalkowski fijall at gmail.com
Tue Mar 6 00:49:03 CET 2012


On Mon, Mar 5, 2012 at 3:40 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>> I strongly disagree that sandbox is secure because it's "just
>> segfaults" and "any code is exploitable that way". Finding segfaults
>> in CPython is "easy". As in all you need is armin, a bit of coffee and
>> a free day. Reasons for this vary, but one of those is that python is
>> a large code base that does not have automatic ways of preventing such
>> issues like C-level recursion.
>>
>> For a comparison, PyPy sandbox is a compiled from higher-level
>> language program that by design does not have all sorts of problems
>> described. The amount of code you need to carefully review is very
>> minimal (as compared to the entire CPython interpreter). It does not
>> mean it has no bugs, but it does mean finding segfaults is a
>> significantly harder endeavour. There are no bug-free programs,
>> however having for example to segfault an arbitrary interpreter
>> *written* in Python would be significantly harder than one in C,
>> wouldn't it?
>
> While this may true, I can't conclude that we should stop fixing
> crashers in CPython, or give up developing CPython altogether. While
> it is a large code base, it is also a code base that will be around
> for a long time to come, so any effort spend on this today will pay
> off in the years to come.
>
> Regards,
> Martin

I did not say that Martin.

PyPy sandbox does not come without issues, albeit they are not the
security related kind.

My point is that it does not make sense do add stuff to CPython to
make sandboxing on the Python easier *while* there are still easily
accessible segfaults. Fixing those issues, should be a priority
*before* we actually start and tinker with other layers. All I'm
trying to say is "if you want to make a sandbox on top of CPython, you
have to fix segfaults".

Cheers,
fijal


More information about the Python-Dev mailing list