On Mon, Feb 23, 2009 at 09:23, tav <tav@espians.com> wrote:
Dearest fellow Python lovers,

Could one of you please review:

 http://codereview.appspot.com/20051

The patch is a mere 6 lines of code and provides the absolute minimum
that is needed to secure the Python interpreter! [This patch is for
Python 2.5.4 -- I can create one for the other branches too if
wanted...]

It turns out that the __builtins__ based restricted framework is pure
genius and gives us nearly everything that's needed to secure our
beloved interpreter. This patch simply closes the two holes in 2.5.x
-- type.__subclasses__ and GeneratorType.gi_frame.
GeneratorType.gi_code would need to be restricted in 2.6 and above.

The problem with rexec and brethren have simply been that we tried to
do class-based sandboxing. This approach is filled with dark
exploitable corners. In contrast, a function-based approach gives us
security through the simplicity of the object-capability model.

If you block __closure__ and __globals__ on function objects you will get a semblance of a private namespace. That way you might (I have not thought this one through like securing the interpreter for embedding) be able to get what you need to safely pass in Python code through the globals of the code being executed.

-Brett
 

Or at least I currently believe so =)

Once this patch gets through onto App Engine, I'll create an app with
a sandboxed framework built around it and you can all prove me wrong.
But, for the sake of my relationship with the missus, I hope not ;p

Please note that this patch doesn't do anything to prevent any of the
various crashers in Python. It is not the intention of this patch to
make the interpreter invincible against segfaults or exhaustion of
resource attacks. For that, I heartily recommend taking a look at
PyPy's sandboxed interpreter and/or the magic of App Engine.

In the extremely remote chance that I am right -- pigs could fly,
right? ;p -- and the sandboxed App Engine app turns out to be
impenetrable, I would like to then get approval to simplify the
current restricted execution support in the interpreter and create a
modernised equivalent of the rexec module.

Does that seem reasonable to you all?

 tav>   http://github.com/tav/plexnet/tree/9dabc570a2499689e773d1af3599a29102071f80/source/plexnet/util

 martin> What is the objective of this code? Is it a complete
 martin> sandbox? If not, is a complete sandbox based on
 martin> it available somehow for review?

Martin, sorry, not yet.

I'll code one once the patch gets through and release it for use/review.

And if people like it, it could form the basis for the modernised
rexec I mentioned above...

 krstic> http://radian.org/~krstic/sandbox.py

Thank you Ivan for that Genshi sample!

Would you be interested in working with me on the Genshi aspect for
the new sandbox framework?

 pje> Just a question, but, if you just need a pure-python
 pje> restricted environment for App Engine, why not just
 pje> use the RestrictedPython package?

I'm aware of the various Zope offerings.

Performance is the answer to your question.

Also, when it comes to security, I am a deep believer in simplicity.

Thanks again!

--
love, tav

plex:espians/tav | tav@espians.com | +44 (0) 7809 569 369
http://tav.espians.com | @tav | skype:tavespian