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

[Brett Cannon]

On 6/29/06, A.M. Kuchling <amk at amk.ca> wrote:
>
> 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).


Huh.  Interesting idea.  I would go with the exception position (pushing
None feels very Lua/JavaScript-like),

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...)


Yeah, that would definitely help with the issue.  And I am not even thinking
of Bastion functionality.  If you want something like that, write a delegate
in C.

And this could be extended so that a list of objects that should be banned
could be added to and checked as needed.  Performance would drop, but I
don't know by how much.

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).


Thanks for the link, Andrew!

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060629/f4f62fe1/attachment.html