[Python-Dev] 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Restricted execution: what's the threat model?
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Restricted execution: what's the threat model?
On 7/12/06, Jim Jewett [EMAIL PROTECTED] 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 thatinterpreter 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 thatthe other interpreter is free to ignore them.Maybe even make itlockable, 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 theinit-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 certainobjects, 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 itwill behave as if its builtins were segregated, and not see changesmade by another interpreter?I am going with your latter assumption in my design. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Restricted execution: what's the threat model?
After reading the messages on this thread i'm starting to think that it would be good to clarify what kinds of threats we are trying to defend against, and specify what invariants we are intending to preserve. For example, here are a few things Brett mentioned: Right. I am thinking more of an implementation screw up that somehow provides access to an object that has escalated rights. But you are correct, I am only concerned with preventing a crash of a sandboxed interperter. [on what is meant by it getting out] Out of a trusted interpreter and ending up in a sandboxed interpreter some how. So here are a couple of questions for clarification (some with my guesses as to their answers): 1. When we say restricted/untrusted/whatever interpreter we don't really mean that the *interpreter* is untrusted, right? We mean that the Python code that runs in that interpreter is untrusted (i.e. to be prevented from doing harm), right? 2. I'm assuming that the implementation of the Python interpreter is always trusted. As a starting point it seems to me we have to draw the line somewhere -- around at least the C code that implements the Python interpreter, and possibly more. What do we take the Trusted Computing Base to include? The Python VM implementation -- plus all the builtin objects and C modules? Plus the whole standard library? (trusted = behaves safely because it's our job to write it correctly, not due to something else imposing restrictions upon it; untrusted = we wish to be able to impose restrictions on it) 3. Is it part of the plan that we want to protect Python code from other Python code? For example, should a Python program/function X be able to say i want to launch/call program/function Y with *these* parameters and have it run under *these* limitations? This has a big impact on the model. And here are some possible goals or invariants to consider. It will be helpful to decide on some of these so that, when someone points to what they think is a flaw in the security implementation, we can say yes, that is our responsibility or no, it isn't. We want to be able to guarantee that... A. The interpreter will not crash no matter what Python code it is given to execute. B. Python programs running in different interpreters embedded in the same process cannot communicate with each other. C. Python programs running in different interpreters embedded in the same process cannot access each other's Python objects. D. A given piece of Python code cannot access or communicate with certain Python objects in the same interpreter. E. A given piece of Python code can access only a limited set of Python objects in the same interpreter. I think in order to get truly useful restricted interpreters we will end up wanting to make guarantees of all of these kinds. There may be others i haven't thought of -- feel free to edit or add others. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Restricted execution: what's the threat model?
Ka-Ping Yee writes: i'm starting to think that it would be good to clarify what kinds of threats we are trying to defend against, and specify what invariants we are intending to preserve. Yes! So here are a couple of questions for clarification (some with my guesses as to their answers): Okay, I'll throw in my thoughts also. 1. When we say restricted/untrusted/whatever interpreter we don't really mean that the *interpreter* is untrusted, right? We mean that the Python code that runs in that interpreter is untrusted (i.e. to be prevented from doing harm), right? Agreed. My interpretation of the proposal was that interpreters were either sandboxed or trusted. Sandboxed means that there are security restrictions imposed at some level (perhaps even NO restrictions). Trusted means that the interpreter implements no security restrictions (beyond what CPython already implements, which isn't much) and thus runs faster. 2. I'm assuming that the implementation of the Python interpreter is always trusted Sure... it's got to be. What do we take the Trusted Computing Base to include? The Python VM implementation -- plus all the builtin objects and C modules? Plus the whole standard library? My interpretation of Brett's proposal is that the CPython developers would try to ensure that Python VM had no security holes when running in sandboxed mode. Of course, we also try to ensure no crashes are possible also, and while we're quite good, we're not perfect. Beyond that, all pure-python modules with source available (whether in the stdlib or not) can be trusted because they run in a sandboxed VM. All C modules are *up to the user*. Brett proposes to provide a default list of useful-but-believed-to-be-safe modules in the stdlib, but the user can configure the C-module whitelist to whatever she desires. 3. Is it part of the plan that we want to protect Python code from other Python code? For example, should a Python program/function X be able to say i want to launch/call program/function Y with *these* parameters and have it run under *these* limitations? This has a big impact on the model. Now *that* is a good question. I would say the answer is a partial no, because there are pieces of Brett's security model that are tied to the interpreter instance. Python code cannot launch another interpreter (but perhaps it *should* be able to?), so it cannot modify those restrictions for new Python code it launches. However, I would rather like to allow Python code to execute other code with greater restrictions, although I would accept all kinds of limitations and performance penalties to do so. I would be satisfied if the caller could restrict certain things (like web and file access) but not others (like memory limits or use of stdout). I would satisfied if the caller paid huge overhead costs of launching a separate interpreter -- heck, even a separate process. And if it is willing to launch a separate process, then Brett's model works just fine: allow the calling code to start a new (restricted) Python VM. We want to be able to guarantee that... A. The interpreter will not crash no matter what Python code it is given to execute. Agreed. We already want to guarantee that, with the caveat that the guarantee doesn't apply to a few special modules (like ctypes). B. Python programs running in different interpreters embedded in the same process cannot communicate with each other. I don't want to guarantee this, does someone else? It's astonishingly hard... there are all kinds of clever knock on the walls tricks. For instance, communicate by varying your CPU utilization up and down in regular patterns. I'd be satisfied if they could pass information (perhaps even someday provide a library making it *easy* to do so), but could not pass unforgable items like Python object references, open file descriptors, and so forth. C. Python programs running in different interpreters embedded in the same process cannot access each other's Python objects. I strengthen that slightly to all unforgable items, not just object references. D. A given piece of Python code cannot access or communicate with certain Python objects in the same interpreter. E. A given piece of Python code can access only a limited set of Python objects in the same interpreter. Hmmm. I'm not sure. -- Michael Chermside ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Restricted execution: what's the threat model?
[replying to both Ping and Michael in the same email]On 7/6/06, Michael Chermside [EMAIL PROTECTED] wrote: Ka-Ping Yee writes: i'm starting to think that it would be good to clarify what kinds of threats we are trying to defend against, and specify what invariants we are intending to preserve.Yes! So here are a couple of questions for clarification (some with my guesses as to their answers): Okay, I'll throw in my thoughts also. 1.When we say restricted/untrusted/whatever interpreter we don't really mean that the *interpreter* is untrusted, right? We mean that the Python code that runs in that interpreter is untrusted (i.e. to be prevented from doing harm), right?Agreed. My interpretation of the proposal was that interpreterswere either sandboxed or trusted. Sandboxed means that there are security restrictions imposed at some level (perhaps even NOrestrictions). Trusted means that the interpreter implementsno security restrictions (beyond what CPython already implements,which isn't much) and thus runs faster. Yep. 2.I'm assuming that the implementation of the Python interpreter is always trustedSure... it's got to be.Yep. What do we take the Trusted Computing Base to include?The Python VM implementation -- plus all the builtin objects and C modules? Plus the whole standard library?My interpretation of Brett's proposal is that the CPython developers would try to ensure that Python VM had no security holes whenrunning in sandboxed mode. Of course, we also try to ensure nocrashes are possible also, and while we're quite good, we're not perfect.Beyond that, all pure-python modules with source available (whetherin the stdlib or not) can be trusted because they run in asandboxed VM. All C modules are *up to the user*. Brett proposes to provide a default list of useful-but-believed-to-be-safe modulesin the stdlib, but the user can configure the C-module whitelistto whatever she desires.Michael has it on the money. 3.Is it part of the plan that we want to protect Python code from other Python code?For example, should a Python program/function X be able to say i want to launch/call program/function Y with *these* parameters and have it run under *these* limitations? This has a big impact on the model.Now *that* is a good question. I would say the answer is a partial no, because there are pieces of Brett's security model that aretied to the interpreter instance. Python code cannot launch anotherinterpreter (but perhaps it *should* be able to?), so it cannot modify those restrictions for new Python code it launches.However, I would rather like to allow Python code to execute othercode with greater restrictions, although I would accept all kindsof limitations and performance penalties to do so. I would be satisfied if the caller could restrict certain things (like weband file access) but not others (like memory limits or use ofstdout). I would satisfied if the caller paid huge overhead costsof launching a separate interpreter -- heck, even a separate process. And if it is willing to launch a separate process, thenBrett's model works just fine: allow the calling code to starta new (restricted) Python VM.The plan is that there is no sandboxed eval() that runs unsafe code from a trusted interpreter within its namespace. I hope to provide Python code access to running a sandboxed interpreter where you can pass in a string to be executed, but the namespace for that sandboxed interpreter will be fresh and will not carry over in any way from the trusted interpreter. We want to be able to guarantee that... A.The interpreter will not crash no matter what Python code it is given to execute.Agreed. We already want to guarantee that, with the caveat that theguarantee doesn't apply to a few special modules (like ctypes).Right, which is why I have been trying to plug the various known crashers that do not rely upon a specific extension module from being imported. B.Python programs running in different interpreters embedded in the same process cannot communicate with each other. I don't want to guarantee this, does someone else? It'sastonishingly hard... there are all kinds of clever knock on thewalls tricks. For instance, communicate by varying your CPUutilization up and down in regular patterns. I'd be satisfied if they could pass information (perhaps evensomeday provide a library making it *easy* to do so), but couldnot pass unforgable items like Python object references, open filedescriptors, and so forth. Or at least cannot communicate without explicit allowances to do so.As for knocking on the walls, if you protect access to that kind of information well, it shouldn't be a problem. C.Python programs running in different interpreters embedded in the same process cannot access each other's Python objects. I strengthen that slightly to all unforgable items, not justobject references.I would change that to add the caveat that what is exposed by a C extension module attribute will be shared. That is an implementation
