[Python-Dev] The pysandbox project is broken

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.


More information about the Python-Dev mailing list