[Python-Dev] Restricted execution: what's the threat model? (original) (raw)

Brett Cannon brett at python.org
Thu Jul 13 00:58:50 CEST 2006

On 7/12/06, Jim Jewett <jimjjewett at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060712/98b621f6/attachment.html

More information about the Python-Dev mailing list