[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