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

[Ka-Ping Yee]

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