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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
