Jim Fulton wrote:
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.
Could that sanitization could be a filter that lets nothing through, and then builds from there?
- 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.
The PyPy guys seem pretty sure you can always break out of this. How would you set up an environment which would meet your criterea and couldn't be broken out of?
...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.
...which the PyPy guys seem to have achieved, if only we could leverage it.
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.
Who is "we"? It certainly doesn't include me :-S Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk