[Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

[Jon Ribbens]

On Sun, Apr 10, 2016 at 02:51:23PM +1000, Nick Coghlan wrote:
> On 9 April 2016 at 22:43, Victor Stinner <victor.stinner at gmail.com> wrote:
> > See pysandbox test suite for a lot of ways to escape a sandbox. CPython has
> > a list of know code to crash CPython (I don't recall the dieectory in
> > sources), even with the latest version of CPython.
> 
> They're at https://hg.python.org/cpython/file/tip/Lib/test/crashers

Thanks. I take your point that sandboxing Python requires CPython to
free of code execution bugs. However I will note that none of the
crashers in that directory will work inside my experiment (except
"infinite_loop_re.py", which isn't a crasher just a long loop).

> Even without those considerations though, there are system level
> denial of service attacks that untrusted code can perform without even
> trying to break out of the sandbox - the most naive is "while 1:
> pass", but there are more interesting ones like "from itertools import
> count; sum(count())", or even "sum(iter(int, 1))" and "list(iter(int,
> 1))".

Yes, of course. I have already explicitly noted that infinite loops
and memory exhausation are not preventable.

> Operating system level security sandboxes still aren't particularly
> easy to use correctly, but they're a lot more reliable than language
> runtime level sandboxes, can be used to defend against many more
> attack vectors, and even offer increased flexibility (e.g. "can write
> to these directories, but no others", "can read these files, but no
> others", "can contact these IP addresses, but no others").

I don't entirely trust operating system sandboxes either - I generally
assume that if someone can execute arbitrary code on my machine, then
they can do anything they want to that machine.

What I *might* trust, though, would be a "sandbox Python" that is
itself running inside an operating system sandbox...