Le 11/06/2011 02:41, R. David Murray a écrit :
I haven't read through your post, but if you don't know about it I
suspect that you will be interested in the following:
http://code.activestate.com/pypm/pysandbox/
I'm pretty sure Victor will be happy to have someone else interested in
this
Hello! This is my first posting to the python-dev list, so please
forgive me if I violate any unspoken etiquette here. :)
I was looking at Python 2.x's f_restricted frame flag (or, rather, the
numerous ways around it) and noticed that most (all?)
of the attacks to escape restricted execution
On Fri, 10 Jun 2011 18:23:47 -0600, Sam Edwards sam.edwa...@colorado.edu
wrote:
Hello! This is my first posting to the python-dev list, so please
forgive me if I violate any unspoken etiquette here. :)
Well, hopefully we won't bite, though of course I can't promise anything
for anyone else :)
Hi Sam,
Have you seen this?
http://tav.espians.com/paving-the-way-to-securing-the-python-interpreter.html
It might relate a similar idea. There were a few iterations of Tav's approach.
--Guido
On Fri, Jun 10, 2011 at 5:23 PM, Sam Edwards sam.edwa...@colorado.edu wrote:
Hello! This is my first
At 06:23 PM 6/10/2011 -0600, Sam Edwards wrote:
I have a couple remaining issues that I haven't quite sussed out:
[long list of questions deleted]
You might be able to answer some of them by looking at this project:
http://pypi.python.org/pypi/RestrictedPython
Which implements the
All,
Thanks for the quick responses!
I've skimmed the pysandbox code yesterday. I think Victor has the right
idea with relying on a whitelist, as well as limiting execution time.
The fact that untrusted code can still execute memory exhaustion attacks
is the only thing that still worries me:
