[Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python] (original) (raw)

Ka-Ping Yee python-dev at zesty.ca
Sat Jul 8 06:28:06 CEST 2006

On Fri, 7 Jul 2006, Talin wrote:

While I was typing this, I did realize a drawback to poisoned objects, which I will illustrate by the following example:

Suppose we want to grant to the sandboxed program permission to read and write cofiguration properties. We don't want to give them arbitrary write access to the file, instead we want to force the sandbox code to only access that file by setting and getting properties. This is an example where a subsystem would require elevated privileges compared to the main program - the config file reader / writer needs to be able to read & write the file as a text stream, but we don't want to allow the sandboxed program to just write arbitrary data to it.

The situation you're describing here is a classic case of one component keeping a closely held authority while using it to provide some limited capability to some other component. This comes up quite often when you're trying to write secure code.

If you want to be able to write that subsystem in Python, then we will need a way to create airtight Python objects (i.e. objects that only leak what they explicitly choose to leak).

So this goes back to the big question of goals:

Do we want to be able to protect one piece of Python code
from another piece of Python code?

I'd like the answer to be yes. It sounded for a while like this was not part of Brett's plan, though. Now i'm not so sure. It sounds like you're also interested in having the answer be yes?

Let's keep talking about and playing with more examples -- i think they'll help us understand what goals we should aim for and what pitfalls to anticipate before we nail down too many details.

-- ?!ng

More information about the Python-Dev mailing list