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

[Ka-Ping Yee]

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