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

Michael Chermside mcherm at mcherm.com
Thu Jul 6 14:37:56 CEST 2006

Ka-Ping Yee writes:

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.

Yes!

So here are a couple of questions for clarification (some with my guesses as to their answers):

Okay, I'll throw in my thoughts also.

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?

Agreed. My interpretation of the proposal was that interpreters were either "sandboxed" or "trusted". "Sandboxed" means that there are security restrictions imposed at some level (perhaps even NO restrictions). "Trusted" means that the interpreter implements no security restrictions (beyond what CPython already implements, which isn't much) and thus runs faster.

2. I'm assuming that the implementation of the Python interpreter is always trusted

Sure... it's got to be.

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?

My interpretation of Brett's proposal is that the CPython developers would try to ensure that Python VM had no "security holes" when running in sandboxed mode. Of course, we also "try" to ensure no crashes are possible also, and while we're quite good, we're not perfect.

Beyond that, all pure-python modules with source available (whether in the stdlib or not) can be "trusted" because they run in a sandboxed VM. All C modules are up to the user. Brett proposes to provide a default list of useful-but-believed-to-be-safe modules in the stdlib, but the user can configure the C-module whitelist to whatever she desires.

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.

Now that is a good question. I would say the answer is a partial "no", because there are pieces of Brett's security model that are tied to the interpreter instance. Python code cannot launch another interpreter (but perhaps it should be able to?), so it cannot modify those restrictions for new Python code it launches.

However, I would rather like to allow Python code to execute other code with greater restrictions, although I would accept all kinds of limitations and performance penalties to do so. I would be satisfied if the caller could restrict certain things (like web and file access) but not others (like memory limits or use of stdout). I would satisfied if the caller paid huge overhead costs of launching a separate interpreter -- heck, even a separate process. And if it is willing to launch a separate process, then Brett's model works just fine: allow the calling code to start a new (restricted) Python VM.

We want to be able to guarantee that...

A. The interpreter will not crash no matter what Python code it is given to execute.

Agreed. We already want to guarantee that, with the caveat that the guarantee doesn't apply to a few special modules (like ctypes).

B. Python programs running in different interpreters embedded in the same process cannot communicate with each other.

I don't want to guarantee this, does someone else? It's astonishingly hard... there are all kinds of clever "knock on the walls" tricks. For instance, communicate by varying your CPU utilization up and down in regular patterns.

I'd be satisfied if they could pass information (perhaps even someday provide a library making it easy to do so), but could not pass unforgable items like Python object references, open file descriptors, and so forth.

C. Python programs running in different interpreters embedded in the same process cannot access each other's Python objects.

I strengthen that slightly to all "unforgable" items, not just object references.

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.

Hmmm. I'm not sure.

-- Michael Chermside

More information about the Python-Dev mailing list