Showing content from http://mail.python.org/pipermail/python-dev/attachments/20160410/4517aabe/attachment.html below:
<p dir="ltr"><br>
On Apr 10, 2016 11:51 AM, "Jon Ribbens" <<a href="mailto:jon%2Bpython-dev@unequivocal.co.uk">jon+python-dev@unequivocal.co.uk</a>> wrote:<br>
><br>
> On Sun, Apr 10, 2016 at 02:51:23PM +1000, Nick Coghlan wrote:<br>
> > On 9 April 2016 at 22:43, Victor Stinner <<a href="mailto:victor.stinner@gmail.com">victor.stinner@gmail.com</a>> wrote:<br>
> > > See pysandbox test suite for a lot of ways to escape a sandbox. CPython has<br>
> > > a list of know code to crash CPython (I don't recall the dieectory in<br>
> > > sources), even with the latest version of CPython.<br>
> ><br>
> > They're at <a href="https://hg.python.org/cpython/file/tip/Lib/test/crashers">https://hg.python.org/cpython/file/tip/Lib/test/crashers</a><br>
><br>
> Thanks. I take your point that sandboxing Python requires CPython to<br>
> free of code execution bugs. However I will note that none of the<br>
> crashers in that directory will work inside my experiment (except<br>
> "infinite_loop_re.py", which isn't a crasher just a long loop).<br>
><br>
> > Even without those considerations though, there are system level<br>
> > denial of service attacks that untrusted code can perform without even<br>
> > trying to break out of the sandbox - the most naive is "while 1:<br>
> > pass", but there are more interesting ones like "from itertools import<br>
> > count; sum(count())", or even "sum(iter(int, 1))" and "list(iter(int,<br>
> > 1))".<br>
><br>
> Yes, of course. I have already explicitly noted that infinite loops<br>
> and memory exhausation are not preventable.<br>
><br>
> > Operating system level security sandboxes still aren't particularly<br>
> > easy to use correctly, but they're a lot more reliable than language<br>
> > runtime level sandboxes, can be used to defend against many more<br>
> > attack vectors, and even offer increased flexibility (e.g. "can write<br>
> > to these directories, but no others", "can read these files, but no<br>
> > others", "can contact these IP addresses, but no others").<br>
><br>
> I don't entirely trust operating system sandboxes either - I generally<br>
> assume that if someone can execute arbitrary code on my machine, then<br>
> they can do anything they want to that machine.<br>
><br>
> What I *might* trust, though, would be a "sandbox Python" that is<br>
> itself running inside an operating system sandbox...<br>
></p>
<p dir="ltr">* <a href="https://github.com/jupyter/jupyterhub/wiki/Spawners">https://github.com/jupyter/jupyterhub/wiki/Spawners</a> <br>
 - Docker LXC Containers<br>
 - <a href="https://github.com/jupyter/jupyterhub/wiki/Authenticators">https://github.com/jupyter/jupyterhub/wiki/Authenticators</a><br>
   - DOS is still trivial<br>
   - Segfault is still trivial<br>
* <a href="http://doc.pypy.org/en/latest/sandbox.html#introduction">http://doc.pypy.org/en/latest/sandbox.html#introduction</a><br>
_______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com">https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com</a><br>
</p>
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