On Fri, Apr 8, 2016 at 3:20 AM, Jon Ribbens <jon+use...@unequivocal.co.uk> wrote: > On 2016-04-07, Random832 <random...@fastmail.com> wrote: >> On Thu, Apr 7, 2016, at 08:13, Jon Ribbens wrote: >>> > All the obvious, and even not-so-obvious, attack tools are gone: >>> > eval, exec, getattr, type, __import__. >> >> We don't even need to take these away, per se. >> >> eval and exec could be replaced with functions that perform the >> evaluation with the same rules in the same sandbox. > > Ah, that's a good point. > > I've put an example script here: > > https://github.com/jribbens/unsafe/blob/master/unsafe.py > > When run as a script, it will execute whatever Python code you pass it > on stdin.
Now we're getting to something rather interesting. Going back to your previous post, though... On Wed, Apr 6, 2016 at 3:26 AM, Jon Ribbens <jon+use...@unequivocal.co.uk> wrote: > The received wisdom is that restricted code execution in Python is > an insolubly hard problem, but it looks a bit like my 7-line example > above disproves this theory ... the thing you were missing in your original example was a LOT of sophistication :) I don't currently have any exploits against your new code, but at this point, it's grown beyond the "hey, if this was insolubly hard, how come seven lines of code can do it?" question. This is the kind of effort it takes to sandbox Python inside Python. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
