[Python-Dev] The pysandbox project is broken (original) (raw)

Christian Heimes christian at python.org
Wed Nov 13 03:09:25 CET 2013

Am 13.11.2013 01:47, schrieb Glenn Linderman:

If it is an implementation issue, then perhaps a different implementation would help. Or perhaps a "safe compiler".

If it is a language design issue, then a different implementation wouldn't help, it would require a new language, or a restricted subset. I'm not sure whether some of the onerous sounding restrictions result from language or implementation issues; some of them certainly sounded like implementation issues. A restricted subset, compiled by a validating compiler, might still be a useful language, even if the execution speed has to be reduced by a validating runtime.

A limited and well-defined subset of Python may do the trick, perhaps a project based on RPython. Zope has a long history of restricted Python code with safe-guards and security proxies. Any project must start with a proper threat model and goals. Does sandboxed code need to access frame objects and use compile()? Could we perhaps use a limited subinterpreters with reduced / modified builtins to archive isolation?

CPython still has a couple of crashers, too. These must be resolved. You don't want sandboxed code to generate a segfault, do you?

Is there technology in the smartphone OSes that could be applied? iOS seems to not even provide a file system to its apps, and there is limited sharing of data from one app to the next. Android provides an explicit subset of system services to its apps.

On Linux seccomp may be a feasible way to prevent syscalls. Seccomp basically can limit the capability of a thread so it can no longer do certain syscalls. Chrome uses it for sandboxing.

Christian

More information about the Python-Dev mailing list