Untrusted code execution

[Jon Ribbens]

On 2016-04-07, Chris Angelico <rosuav at gmail.com> wrote:
> 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.

Well, it entirely depends on how much you're trying to allow the
sandboxed code to do. Most of the stuff in that script (e.g.
_copy_module and safe versions of get/set/delattr, exec, and eval)
I don't think is really necessary for most sensible applications
of such an idea, I've just added it for completeness and to see
if it introduces any security holes that weren't there originally.

I could slim down the code again by simply removing all that extra
cruft and the principle would still be the same - it's only the
safe_compile() function that's adding anything interesting that
I haven't seen done before (and half of the lines in that function
are docstring or stuff to make nicer error messages).