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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4