Executing untrusted code

[Emanuele D'Arrigo]

Christian, Rami and Steven, thank you all for your help. It wasn't
meant to be a challenge, I knew it ought to be easily breakable. I'm
no hacker and it just helps to have some examples to better understand
the issue.

On Aug 20, 7:42 pm, Steven D'Aprano <st... at REMOVE-
> On a related topic, you should read this post here:
> http://tav.espians.com/a-challenge-to-break-python-security.html

Indeed I did read the post and my minimalistic test was inspired by
some of the code in it (I didn't know you could replace the
builtins!). Tav's effort kinda of ended nowhere though. My
understanding of it is that it hasn't been broken and that Tav has
submitted a patch to secure some of python's innards. But

Steven, you are perfectly right, I didn't test it and I missed the
crucial part in which I store the __builtins__ dictionary in the
dictionary of the new originalBuiltins module. My bad. Still, you did
understand my intentions and did give me a simple example of how it
could be broken. Thank you.

-However- I would suggest that conceptually the "award" goes to
Christian. ;)

In the same way the open builtin function can be replaced or removed,
also reload, file, __import__, exec, execfile and any other
potentially "unsafe" builtin can be replaced with safer versions. Or
not?

Christian's solution though, seems to be much trickier to evade. Can
the object class be replaced at runtime with a version that does not
provide a way to reach its subclasses?

Manu