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