PyPy's sandboxing hasn't been as thoroughly analyzed and tested as, say, Javascript's (not by far) or Java's, but the actual construction is simpler and arguabl

PyPy's sandboxing hasn't been as thoroughly analyzed and tested as, say, Javascript's (not by far) or Java's, but the actual construction is simpler and arguably better. The PyPy devs, at least, are fairly convinced of its robustness. Basically they whitelist system calls and all other calls are translated to sandboxed calls during compilation of the sandboxed interpreter, as I recall. This is entirely different from CPython's restricted execution, which was essentially a blacklist of Python calls/attributes-- every attempt at such a system has died a death of a thousand cuts; it really pays to do it from the bottom up like PyPy or E. It might not be ready for prime-time in some very critical systems (like a web browser for example) but it's honestly probably good enough for this, especially in combination with process jailing as you suggest. I might consider trying to patch Cells up to use PyPy's sandbox instead of the non-solution currently implemented (I cried (okay, groaned) when I heard about it-- yeagh), when I have time, and if nobody else does it first. I'm a bit worried anything I write now would get lost or broken in the incoming tide of patches/changes anyway. The main problems with using PyPy's sandboxing is probably with communication to/out of the sandbox, which is apparently problematic. I also anticipate some complaints about relying on PyPy in the first place, which is rather abnormal compared to using CPython-- using and relying on PyPy-specific features is pretty much unheard of.