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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4