On Oct 24, 2008, at 10:01 AM, Chris Withers wrote:
Jim Fulton wrote:
The problem is that it it starts with an environment in which things are allowed by default, and takes things away. This means that if anything is forgotten, then you end up with holes.
Isn't there a way we could change the AST manipulation such that we start with nothing and only allow opcodes as and when they're added to the RestrictedPython implementation?
No. we're starting with an existing program written in a Python script or expression. We then have to sanitize it.
The Zope 3 security proxy approach is much better
I agree, but it doesn't solve all the problems. My understanding of the original set of requirements which we're trying to solve here was basically that of Python Scripts: to allow python code to be written through the web. This means:
- restricting access to atributes of objects (security proxies give us this, right?)
Yes
- restricting access to features of the language such as imports such that unsafe things such as stripping security proxies can't be done. (security proxies *don't* give us this, right?)
Yes, they do, as long as all builtins, including __import__, are wrapped and as long as you only include safe builtins.
...and some nice to haves:
- restricting memory used by executing the code - restricting cpu used by executing the code
These require deep changes to the interpreter.
I know RestrictedPython doesn't support these last two very well, but there are hints that it would have liked to if it could.
It can't support these at all.
I'm not sure that the PyPy guys are really authorities on the sorts of problems we're trying to address, although there is some overlap.
Who is then? ;-)
In the Python community, I;d say we are. Beyond that, I don't know. Jim -- Jim Fulton Zope Corporation