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

Ka-Ping Yee python-dev at zesty.ca
Thu Jul 6 08:11:14 CEST 2006

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/ 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")

  1. 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

More information about the Python-Dev mailing list