[Python-3000] Will we have a true restricted exec environment for python-3000?
Ian Bicking
ianb at colorstudy.com
Mon Apr 10 18:37:22 CEST 2006
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 / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Python-3000
mailing list