Extending subinterpreters with sandboxing capabilities

I’ve been investigating various ways to easily implement sandbox environments in python to run untrusted code but all in vain. It’s so easy for the untrusted code to escape the sandbox environment. I hit the very snag that @vstinner did with pysandbox.

However it occurred to me that subinterpreters are quite independent runtimes of their own, and we could probably extend them to contain sandboxing capabilities. This would mean to limit their access to certain resources and functionality. With the configuration struct, I think it could be possible to include more options tailored to creating sandboxes.

This is just a thought I’ve had for the passed 2 days and haven’t carried out thorough study of it, but I’m somehow convinced it can be done. I just need some opinions about this perhaps.

1 Like

Don’t go there, you’ll be burned.

Sorry I don’t have much more time to elaborate. It all depends on what kind of sandboxing you want and what kind of capabilities you want to allow; I suggest defining that first.
Here’s one example of what to think about:

for n in range(200):
    hog = list(range(2**n))

I suggest looking into Wasm or container-based tools instead.

Also, look at the history of the bastion stdlib module, and why that got removed.

1 Like

Can confirm. Have been there; was burned.

Ditto on the burning; importlib exists because of my attempt.

If you want Python in a sandbox you’re probably best using the WASI build of CPython.

Don’t do that:

Just don’t do that. Thanks :wink:

3 Likes

Run the Python process in a sandbox, don’t run a sandbox in Python…

4 Likes