<http://lists.canonical.org/pipermail/kragen-tol/2002-January/000656.html> > Python, despite having type- and pointer-safety, isn't out-of-the-box > well-suited for running mutually untrusting chunks of code in the same > program. The restricted-execution module for Python had to add a bit > to the Python interpreter that indicates whether code is runing "in > restricted mode" or not. Code running "in restricted mode" can't > access certain "dangerous" attributes of any object, such as __dict__. > From my point of view, this is a problem; accessing __dict__ is > fundamental to extending the Python language, but any objects that > access their __dict__s will break in restricted mode.
What KeyKOS had (and I suppose Eros et.al. continue with) is the "sense key". The problem is that one is concerned with a transitive chain of reachable objects. <http://www.cap-lore.com/CapTheory/KK/Arch/Sensory.Keys.html> On a bare machine, it's easy to explain: pointers are dangerous because if one has one, one can always write as well as read. (Is this the case with Python __dicts__?) Even if one takes advantage of protection, it's still possible to do a lookup through a read-only pointer and get a pointer to non-read-only memory. That'd be a "fetch key". The "sense key" is special in that it behaves like a "fetch key", except that it has the Midas touch: whatever keys one acquires through a sense key are also sensory keys (even if the real key in the node is a stronger one). I think Python has fetch-key-like behavior, so if one has access to a __dict__, and that __dict__ (transitively) has access to some "dangerous" object, the best they can do is to cut off all "not known safe" access up front. If there were a sense-key-like lookup for __dict__s, then restricted code could get an unrestricted __dict__, but they wouldn't be able to get anything but other restricted objects out of it. (safety via facets) > In KeyKOS there were different keys to a domain for merely invoking it > and for debugging it. > > The debugger, of course, also needs access to __dict__ or its > equivalent. The "Scheme as a capability system" paper mentions this > as an obstacle to building Schemes that have no holes in the type > system: the debugger needs the holes. > > It seems to me that the solution is to have pointers to different > facets of the same object: one that allows reflection (with __dict__ > and func_globals and so forth) and one that doesn't. Debuggers should > be able to find the reflection-allowed facet, assuming they already > have it, given the reflection-forbidden facet... That'd be "rights amplification" in KeyKOS. It's also necessary, but I think the sense vs. fetch distinction is more important in your complaint above. -Dave :: :: :: Guido van Rossum, "[Python-Dev] new features for 2.3?" <http://mail.python.org/pipermail/python-dev/2003-January/031881.html> > > > It turns out that in 2.2 and beyond, not enough restrictions were > > > placed on disallowing new introspections that were enabled by > > > virtue of the class/type integration, and that's the cause of most > > > rexec vulnerabilities. > > > > Is there any desire to bother to fix this? Or would it be better to > > just rip this stuff out and hope some TrustedPython project pops up > > to take over rexec, Bastion, and such and do the work of making > > secure Python code? > > I'd like the restricted mode even if it's not perfect, and I hope one > day it will work again. It's mostly a matter of lack of brain cycles.
