Untrusted code execution

[Steven D'Aprano]

On Thursday 07 April 2016 13:40, Random832 wrote:

> On Wed, Apr 6, 2016, at 21:45, Steven D'Aprano wrote:
>> And you would have to do something about the unfortunate matter that
>> modules
>> have a reference to the unrestricted __builtins__:
>> 
>> py> os.__builtins__['eval']
>> <built-in function eval>
> 
> Well, I thought that the solution being discussed uses AST to generally
> forbid accessing attributes beginning with _ (you could also implement a
> whitelist there)


Sure, but I'm just demonstrating that the unrestricted builtins are just one 
attribute lookup away. And as Chris points out, if you have (say) the os 
module, then:

magic = os.sys.modules[
    ''.join(chr(i-1) for i in (96,96,99,118,106,109,117,106,111,116,96,96))
    ][''.join(chr(i+17) for i in (84,101,80,91))]


and that's Game Over.


It's not that this necessarily can't be done, but that it's sufficiently 
hard that very few people are willing to tackle it, and those who are, even 
fewer have come even close to a working restricted Python. PyPy has a 
sandbox, but I believe that relies on OS-level features like jails, and I 
don't really know how well it works.

The problem with sandboxing Python is that it's a game of cat and mouse: you 
eliminate one hole, and then wait for somebody to publish the next hole, 
then eliminate that, and so on. Will this process converge on a useful 
subset of Python? Perhaps. Will it happen soon? Even more doubtful.

Nobody says that its impossible. Only that its hard, real hard, and probably 
much harder than anyone thinks.



-- 
Steve