Guido van Rossum wrote:
I've received some enthusiastic emails from someone who wants to
revive restricted mode. He started out with a bunch of patches to the
CPython runtime using ctypes, which he attached to an App Engine bug:
http://code.google.com/p/googleappengine/issues/detail?id=671
Based on his code (the file secure.py is all you need, included in
secure.tar.gz) it seems he believes the only security leaks are
__subclasses__, gi_frame and gi_code. (I have since convinced him that
if we add "restricted" guards to these attributes, he doesn't need the
functions added to sys.)
I don't recall the exploits that Samuele once posted that caused the
death of rexec.py -- does anyone recall, or have a pointer to the
threads?
I don't have much time these days, for sure not until pycon us, to look
at the proposed code.
A remark though, in many cases people want to use restricted execution
to allow trusted and untrusted code to live side by side. In such a
scenario the issue is not only how to prevent for example the untrusted
code to get hold of open() but also how to deal with the security issues
at the boundary when untrusted code calls into trusted code. AFAIK E
provides and incorporate a lot of thinking around the concept of guards,
a sort of generalized runtime "type checking" with very strong
guarantees, in a language like Java instead type checking and final
classes can be used to provide the required safety. Python instead over
the years has grown more hooks for object to cheat about their types. In
general safely programming such trusted code in python will be delicate
and slightly cumbersome. Think for example of thinhs that can be done by
objects redefining equality wrt data structures that old sensitive
information unless such arguments are blocked.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
