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

[Guido van Rossum]

On 7/8/06, Ka-Ping Yee <python-dev at zesty.ca> wrote:
> 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.

I'd like the answer to be no, because I don't believe that we can
trust the VM to provide sufficient barriers. The old pre-2.2
restricted execution mode tried to do this but 2.2 punched a million
holes in it. Python isn't designed for this (it doesn't even enforce
private attributes). I guess this is also the main reason I'm
skeptical about capabilities for Python.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)