[Python-Dev] Restricted execution: what's the threat model?
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.
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev