[Python-Dev] Reviving restricted mode?

[Guido van Rossum]

On Sun, Feb 22, 2009 at 9:54 AM, Benjamin Peterson <benjamin at python.org> wrote:
> On Sun, Feb 22, 2009 at 10:45 AM, Guido van Rossum <guido at python.org> 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.)
>
> We have to remember that it's quite trivial to segfault the
> interpreter with pure Python. (See Lib/test/crashers)

I know it well, but for this particular use case that doesn't matter.
Tav is interested in using this on app engine, which doesn't care
about segfaults -- the process is simply restarted, nobody gains
access to information they shouldn't have. App engine does care about
overwriting memory, but none of the crashers get that far in the
configuration on app engine.

> Even if this patch manages to plug all the holes in the current
> Python, do we really want to commit our selves to maintaining it
> through language evolution which will surely introduce new subtle ways
> to circumvent the guard?

You'd have to talk to Tav about this (I've CC'ed him on this message).
He seems quite convinced that his current approach is secure, all he
wants is a way to do the equivalent in app engine (where ctypes is not
supported and never will be).

> IMO, the only fairly close to fool proof method of running restricted
> python is through something like the PyPy sandbox where all os level
> calls have to be checked by the master process.

Trust me, app engine has something similar -- Tav's desire is just to
provide an added barrier between his app and code that his app will
let users run within a context it provides. He's relying (forced to
rely :-) on app engine's sandbox for protection against illegal
syscalls.

>> 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?
>
> It was broken by the introduction of new-style classes:
>
> http://mail.python.org/pipermail/python-dev/2002-December/031160.html

I think there were other threads where Samule showed some quite
devious ways to access the os module. I don't see any posts by Samuele
in that thread (and he just replied that he's too busy). The attack
demonstrated at the top of that thread isn't particularly interesting
-- it just shows that class-based security doesn't work so well, but
that doesn't mean some other approach based more on functions couldn't
work.

For Tav's benefit, I think it would be good to at least add
"IsRestricted" checks to __subclasses__(), go_code and gi_frame --
that's a trivial patch and if he believes it's enough he can create a
sandbox on app engine and invite people to try to break out of it...
If someone succeeds, the damage is limited by app engine's own
perimeter defenses (which haven't been broken through since it was
released 9 months ago).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)