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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4