Nick Coghlan wrote: > And once you move to an out-of-process sandbox, then the only Python specific > issue remaining is improving the support for inter-process communications. > The > security issues are then more in the domain of the OS: > - controlling file access permissions on a per-process basis > - controlling network access permissions on a per-process basis > - limiting the memory usage of a process > - limiting the CPU usage of a process
This seems like an option that isn't given enough attention. Providing management routines and better IPC could provide a non-portable (but usable) restricted execution system more easily than other techniques, and serve as a starting point. From there I can imagine adding these restrictions into the bytecode interpreter directly, so that things like opening files was disallowed. Any non-restricted routines would go through some IPC code. AFAIK, this is basically the Javascript security model -- where the DOM or XPCOM or somesuch is used for everything that isn't purely sandbox code. This is a bit similar to what Vineet proposed, except that any modules added to the subinterpreter would either be run with the same restrictions as the rest of the subinterpreter, or a proxy to the module would be passed to the subinterpreter that could be used to communicate in a limited fashion to the parent interpreter. One advantage to this is that at each step something useful would be created. Better IPC would be useful for more than restricted execution. Or ways to create subinterpreters and communicate with them. Or making the interpreter startup faster, to facilitate spawning short-lived interpreters. As an example, by combining these features but leaving out restricted execution you can get something like the PHP model, which manages to protect well against buggy code (even if not so well against security bugs). There's probably a dozen distinct parts to this, but I think each is independently interesting and useful. And maybe, because these are useful subprojects, some of the people who can't commit to the time to take on this project as a whole could commit to some piece of it for which they have alternate motivations. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
