[Python-Dev] Re: Capabilities

[Jeremy Hylton]

On Sat, 2003-03-08 at 07:27, Ben Laurie wrote:
> Bound methods are not capabilities unless they are secured. It seems the 
> correct way to do this is to use restricted execution, and perhaps some 
> other tricks. What I am trying to nail down is exactly what needs doing 
> to get us from where we are now to where capabilities actually work. As 
> I understand it, what is needed is:
> 
> a) Fix restricted execution, which is in a state of disrepair
> 
> b) Override import, open (and other stuff? what?)
> 
> c) Wrap or replace some of the existing libraries, certify that others 
> are "safe"
> 
> It looks to me like a and b are shared with proxies, and c would be 
> different, by definition. Is there anything else? Am I on the wrong track?

I have been trying to argue, though I feel a bit muddled at times, that
the proxy approach eliminates the need for rexec and makes it possible
to build a "restricted environment" without relying on the rexec code in
the interpreter.

Any security scheme needs some kind of information hiding to guarantee
that untrusted code does not break into the representation of an object,
so that, for example, an object can be used as a capability.  I think
we've discussed two different ways to implement information hiding.

The rexec approach is to add code to the interpreter to disable certain
introspection features when running untrusted code.

The proxy approach is to wrap protected objects in proxies before
passing them to untrusted code.

I think both techniques achieve the same end, but with different
limitations.  I prefer the proxy approach because it is more self
contained.  The rexec approach requires that all developers working in
the core on introspection features be aware of security issues.  The
security kernel ends up being most of the core interpreter -- anything
that can introspection on objects.  The proxy approach is to create an
object that specifically disables introspection by not exposing
internals to the core.  We need to do some more careful analysis to be
sure that proxies really achieve the goal of information hiding.

I think another benefit of proxies vs. rexec is that untrusted code can
still use all of the standard introspection features when dealing with
objects it creates itself.  Code running in rexec can't use any
introspective feature, period, because all those features are disabled. 
With the proxy approach, introspection is only disabled on protected
objects.

> I am going to write this all up into a document which can be used as a 
> starting point for work to complete this.

It sounds like a PEP would be the right thing.  It would be nice if the
PEP could explain the rationale for a secure Python environment and then
develop (at least) the capability approach to building that
environment.  Perhaps I could chip in with some explanation of the proxy
approach.

Jeremy