[Python-Dev] Restricted execution: what's the threat model?

[Brett Cannon]

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