Restricted execution: what's the threat model?
Ka-Ping Yee writes:
A. The interpreter will not crash no matter what Python code it is given to execute.
Why? We don't want it to crash the embedding app (which might be another python interpreter), but if the sandboxed interpreter itself crashes, is that so bad? The embedding app should just act as though that interpreter exited, possibly with a status code.
B. Python programs running in different interpreters embedded in the same process cannot communicate with each other.
Why not? Can't eavesdrop, yes. Can't force a connection, so that the other interpreter is free to ignore them. Maybe even make it lockable, like sockets -- but it isn't something worth promising.
C. Python programs running in different interpreters embedded in the same process cannot access each other's Python objects.
Note that Brett's assumption of shared extension modules violates this -- but I'm not sure why he needs to assume that. (Because of the init-only-once semantics, I'm not even sure it is a good idea to share them.)
D. A given piece of Python code cannot access or communicate with certain Python objects in the same interpreter.
Why not? Is this just a way of allowing lightweight subinterpreters? Or do you really mean that they can't replace or modify certain objects, such as the permission-controlling code?
E. A given piece of Python code can access only a limited set of Python objects in the same interpreter.
Does this include objects it creates? Or are you just saying that it will behave as if its builtins were segregated, and not see changes made by another interpreter? -jJ
On Jul 12, 2006, at 2:23 PM, Jim Jewett wrote:
Ka-Ping Yee writes:
A. The interpreter will not crash no matter what Python code it is given to execute.
Why?
We don't want it to crash the embedding app (which might be another python interpreter), but if the sandboxed interpreter itself crashes, is that so bad? The embedding app should just act as though that interpreter exited, possibly with a status code.
When he says crash, I'd have to imagine that he means of the segfault variety. Good luck saving the embedding app after that.
C. Python programs running in different interpreters embedded in the same process cannot access each other's Python objects.
Note that Brett's assumption of shared extension modules violates this -- but I'm not sure why he needs to assume that. (Because of the init-only-once semantics, I'm not even sure it is a good idea to share them.)
Well if you don't share them, you can't have them at all other than in the main trusted interpreter. C extensions can only be safely initialized once and they often cache objects in static variables... lots of C modules aren't even safe to use when combined with multiple interpreters and threads (e.g. PyGILState API), so I guess that perhaps the C API should be refined anyway. -bob
On 7/12/06, Jim Jewett <jimjjewett@gmail.com> wrote:
Ka-Ping Yee writes:
A. The interpreter will not crash no matter what Python code it is given to execute.
Why?
We don't want it to crash the embedding app (which might be another python interpreter), but if the sandboxed interpreter itself crashes, is that so bad? The embedding app should just act as though that interpreter exited, possibly with a status code.
As Bob said, "crash" means segfaulting the Python proceess. Can't exactly save yourself from that one easily. =)
B. Python programs running in different interpreters embedded
in the same process cannot communicate with each other.
Why not? Can't eavesdrop, yes. Can't force a connection, so that the other interpreter is free to ignore them. Maybe even make it lockable, like sockets -- but it isn't something worth promising.
From an initial design point it is. It is an assumption I want to be able to make about the design. If we can come up with a reasonable way for it to work, great. But to begin with, I am assuming objects created within an interpreter will not be passed into another one.
C. Python programs running in different interpreters embedded
in the same process cannot access each other's Python objects.
Note that Brett's assumption of shared extension modules violates this -- but I'm not sure why he needs to assume that. (Because of the init-only-once semantics, I'm not even sure it is a good idea to share them.)
Security reasons. If I can get a Python object in other interpreter with more rights to do something for me I have a serious problem. Do realize that things assumed might have to be made true as much as possible. And in my Threat Model list, I have the caveat that C extension modules are exempt from this.
D. A given piece of Python code cannot access or communicate
with certain Python objects in the same interpreter.
Why not? Is this just a way of allowing lightweight subinterpreters? Or do you really mean that they can't replace or modify certain objects, such as the permission-controlling code?
This one is not in my Threat Model.
E. A given piece of Python code can access only a limited set
of Python objects in the same interpreter.
Does this include objects it creates? Or are you just saying that it will behave as if its builtins were segregated, and not see changes made by another interpreter?
I am going with your latter assumption in my design. -Brett
participants (3)
-
Bob Ippolito -
Brett Cannon -
Jim Jewett