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?
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?) - 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?) ...and some nice to haves: - restricting memory used by executing the code - restricting cpu used by executing the code I know RestrictedPython doesn't support these last two very well, but there are hints that it would have liked to if it could.
to do code manipulation. It still uses restricted Python do deal in a narrow way with basic objects, like strings and numbers, that are unproxied. It's use of restricted Python is so narrow that it is far less problematic. It would be really great if Zope 2 would switch to security proxies, although the transition is likely to be painful.
How would you see the problem of the second requirement above being met?
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? ;-)
If I remember correctly, they are just focussed on protecting the system from untrusted scripts. Our problem is harder because we also want to protect objects available to the scripts.
Indeed :-( Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk