<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 8 April 2016 at 16:18, Jon Ribbens <span dir="ltr"><<a href="mailto:jon+python-dev@unequivocal.co.uk" target="_blank">jon+python-dev@unequivocal.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I've made another attempt at Python sandboxing, which does something<br>
which I've not seen tried before - using the 'ast' module to do static<br>
analysis of the untrusted code before it's executed, to prevent most<br>
of the sneaky tricks that have been used to break out of past attempts<br>
at sandboxes.<br>
<br>
In short, I'm turning Python's usual "gentleman's agreement" that you<br>
should not access names and attributes that are indicated as private<br>
by starting with an underscore into a rigidly enforced rule: try and<br>
access anything starting with an underscore and your code will not be<br>
run.<br>
<br>
Anyway the code is at <a href="https://github.com/jribbens/unsafe" rel="noreferrer" target="_blank">https://github.com/jribbens/unsafe</a><br>
It requires Python 3.4 or later (it could probably be made to work on<br>
Python 2.7 as well, but it would need some changes).<br>
<br>
I would be very interested to see if anyone can manage to break it.<br>
Bugs which are trivially fixable are of course welcomed, but the real<br>
question is: is this approach basically sound, or is it fundamentally<br>
unworkable?<br></blockquote><div><br></div><div>If i'm not mistaken, this breaks out:</div><div><br></div><div>> exec('open("out", "w").write("a")', {})</div><div><br></div><div>because if the second argument of exec does not contain a __builtins__ key, then a copy of the original builtins module is inserted: <a href="https://docs.python.org/3/library/functions.html#exec">https://docs.python.org/3/library/functions.html#exec</a></div><div> </div></div><br></div></div>