[Python-Dev] For sandboxing: alternative to crippling file() (original) (raw)

A.M. Kuchling amk at amk.ca
Thu Jun 29 21:14:42 CEST 2006

On Thu, Jun 29, 2006 at 11:48:36AM -0700, Brett Cannon wrote:

My worry, as has been from the start, is containing 'file'. The ``del builtins`` bug for 'rexec' started me as skittish towards hiding stuff from the built-in namespace. And knowing how easy it tends to be to get at objects and types in Python in general makes me worry even more about hiding objects and types properly from people (within reason, of course; if you

Random, only tangentially-related thought: what if each interpreter had a blacklist of objects that should never be made available to untrusted code? You could then put builtins, file, and anything else on this list. Then, using some #ifdef'ery in ceval.c, check if an object is on this blacklist before pushing it onto the evaluation stack; if it's a blacklisted object, replace it with None (or raise an exception).

This entails a performance hit and makes it impossible to support Bastion-like functionality, where untrusted code could call code that would be treated as trusted, but it also means that, even if you find some type(foo).dict['blah'].co_magic incantation that lets you get to a dangerous type object or module, it wouldn't matter because the dangerous value is silently substituted, and the untrusted code has no way of breaking out of this. (Could you fool a C extension into doing stuff with a dangerous object? Don't know...)

This thought was sparked by the piece on failure-oblivious computing in today's Linux Weekly News about this paper: http://www.usenix.org/events/osdi04/tech/rinard.html. The authors tried continuing to run after a memory error instead of segfaulting: out-of-bounds writes were ignored, and OOB reads returned generated values. See the LWN discussion for more (subscribers only).

--amk

More information about the Python-Dev mailing list