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

[Nick Coghlan]

On 9 April 2016 at 22:43, Victor Stinner <victor.stinner at gmail.com> wrote:
> Please don't loose time trying yet another sandbox inside CPython. It's just
> a waste of time. It's broken by design.
>
> Please read my email about my attempt (pysandbox):
> https://lwn.net/Articles/574323/
>
> And the LWN article:
> https://lwn.net/Articles/574215/
>
> There are a lot of safe ways to run CPython inside a sandbox (and not rhe
> opposite).
>
> I started as you, add more and more things to a blacklist, but it doesn't
> work.
>
> 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

There's also https://hg.python.org/cpython/file/tip/Lib/test/test_crashers.py
which was designed to run them regularly to catch when they were
resolved, but it was too fragile and tended to hang the buildbots.

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))".

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").

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia