<br><br><div><span class="gmail_quote">On 6/29/06, <b class="gmail_sendername">A.M. Kuchling</b> <<a href="mailto:amk@amk.ca">amk@amk.ca</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thu, Jun 29, 2006 at 11:48:36AM -0700, Brett Cannon wrote:<br>> My worry, as has been from the start, is containing 'file'. The ``del<br>> __builtins__`` bug for 'rexec' started me as skittish towards hiding stuff
<br>> from the built-in namespace. And knowing how easy it tends to be to get at<br>> objects and types in Python in general makes me worry even more about hiding<br>> objects and types properly from people (within reason, of course; if you
<br><br>Random, only tangentially-related thought: what if each interpreter<br>had a blacklist of objects that should never be made available to<br>untrusted code? You could then put __builtins__, file, and anything<br>else on this list. Then, using some #ifdef'ery in
ceval.c, check if<br>an object is on this blacklist before pushing it onto the evaluation<br>stack; if it's a blacklisted object, replace it with None (or raise an<br>exception).</blockquote><div><br>Huh. Interesting idea. I would go with the exception position (pushing None feels very Lua/JavaScript-like),
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This entails a performance hit and makes it impossible to support<br>Bastion-like functionality, where untrusted code could call code that
<br>would be treated as trusted, but it also means that, even if you find<br>some type(foo).__dict__['blah'].co_magic incantation that lets you get<br>to a dangerous type object or module, it wouldn't matter because the<br>
dangerous value is silently substituted, and the untrusted code has no<br>way of breaking out of this. (Could you fool a C extension into doing<br>stuff with a dangerous object? Don't know...)</blockquote><div><br>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.
<br><br>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.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This thought was sparked by the piece on failure-oblivious computing<br>in today's Linux Weekly News about this paper:<br><a href="http://www.usenix.org/events/osdi04/tech/rinard.html">http://www.usenix.org/events/osdi04/tech/rinard.html
</a>. The authors<br>tried continuing to run after a memory error instead of segfaulting:<br>out-of-bounds writes were ignored, and OOB reads returned generated<br>values. See the LWN discussion for more (subscribers only).
</blockquote><div><br>Thanks for the link, Andrew!<br><br>-Brett<br></div><br></div>