[Python-Dev] Reviving restricted mode?
Samuele Pedroni
pedronis at openend.se
Sun Feb 22 19:13:56 CET 2009
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.
More information about the Python-Dev
mailing list