[Python-Dev] Reviving restricted mode?

[Samuele Pedroni]

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.