[Python-Dev] Sandboxing Python

[Mark Shannon]

Armin Rigo wrote:
> Hi all,
> 
> On Sun, Mar 4, 2012 at 03:51, Guido van Rossum <guido at python.org> wrote:
>> Could we put asserts in the places where segfaults may happen?
> 
> No.  I checked Lib/test/crashers/*.py and none of them would be safe
> with just a failing assert.  If they were, we'd have written the
> assert long ago :-(  "mutation_inside_cyclegc.py" is not tied to a
> particular place in the source; "loosing_mro_ref.py" requires an extra
> INCREF/DECREF in a performance-critical path; etc.
> 
> Changing CPython to make it truly secure is definitely either a lost
> cause or a real major effort, and pysandbox just gives another such
> example.  My advise is to give up and move security at some other
> level.

I don't think it is as hard as all that.
All the crashers can be fixed, and with minimal effect on performance.
(although the gc module might need couple of function removed)

> 
> (Or else, if you want to play this game, there is PyPy's sandboxing,
> which is just an unpolished proof a concept so far.  I can challenge
> anyone to attack it, and this time it includes attempts to consume too
> much time or memory, to crash the process in any other way than a
> clean "fatal error!" message, and more generally to exploit issues
> that are dismissed by pysandbox as irrelevant.)

Using too much memory can be dealt with at one place (in the allocator).
You can't solve the too much time, without solving the halting problem,
but you can make sure all code is interruptable (i.e. Cntrl-C works).

Cheers,
Mark.