[Python-Dev] Re: Capabilities

[Ben Laurie]

Jeremy Hylton wrote:
> 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.

Wouldn't that suggest that the way to fix restricted execution is to do 
something proxylike, then?

> 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.

Yes.

> 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.

Again, this suggests to me that perhaps restricted execution should also 
use wrapping. I guess I will study this idea in more detail when I start 
writing.

> 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.

If restricted execution were implemented in the same way, then proxies 
and restricted execution would both benefit from this analysis.

> 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.

Right - this does seem like a desirable feature.

>>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.

That would be excellent! I will write a draft as specified in PEP 1.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff