[Python-Dev] Reviving restricted mode?

[Brett Cannon]

On Mon, Feb 23, 2009 at 09:23, tav <tav at 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<http://radian.org/%7Ekrstic/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 at espians.com | +44 (0) 7809 569 369
> http://tav.espians.com | @tav | skype:tavespian
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090223/33e9be29/attachment.htm>