Untrusted code execution

[Chris Angelico]

On Fri, Apr 8, 2016 at 3:20 AM, Jon Ribbens
<jon+usenet at unequivocal.co.uk> wrote:
> On 2016-04-07, Random832 <random832 at 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+usenet at 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