[Python-Dev] Re: Capabilities
Sun, 09 Mar 2003 12:45:39 +0000
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
>>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.
> 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
> 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
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
That would be excellent! I will write a draft as specified in PEP 1.
"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