from Hacker News

Preventing Python "Sandbox" Escape?

by high_byte on 11/26/24, 10:39 AM with 13 comments

I'm using python's exec(code, globals, locals)

I disable __builtins__ so no imports, exec, eval, open, etc. inside that context

but it seems you can still always do object.__subclasses__() and find every system method (eg. open())

it can't be overwritten but looking at the interpreter code is seems like it's possible to hack a workaround for this specific case.

are there other known ways to escape exec()?

by zahlman on 11/27/24, 1:06 AM
Relevant:
https://discuss.python.org/t/extending-subinterpreters-with-...
https://stackoverflow.com/questions/3068139
https://wiki.python.org/moin/SandboxedPython
https://github.com/jailctf/pyjailbreaker
https://healeycodes.com/running-untrusted-python-code
https://lwn.net/Articles/574215/
by Terr_ on 11/26/24, 11:07 AM
I would infer that it's insecure, since if it were that easy there wouldn't be various abandoned projects trying to sandbox Python.
It's the curse of any sufficiently useful language. Well, maybe not Lua, but that was specifically designed for embedding. Java also began with that intention back when applets were ahead of their time, though IIRC secure sandboxing is no longer really a feature.
by eesmith on 11/26/24, 11:05 AM
Don't do it. Really, really don't do it. People have tried for decades to develop such a sandbox, and it does not work.
by billpg on 11/26/24, 10:58 AM
I'm interested in an answer. Is there a way, by design, to run code from an untrusted source in a restricted manner? So the worse the code could do is call me rude names.
by PixelNomad_123 on 11/26/24, 12:59 PM
I agree with eesmith. DONT DO IT. I guess you got your answer restrictedPy