open == file considered harmful (Re: [Python-Dev] RE: rexec.pyunuseable) (original) (raw)

Guido van Rossum guido at python.org
Thu Dec 18 10:38:03 EST 2003

>>It would be a lot better if we could get away from the idea >>of a "restricted mode" in the sense of a flag somewhere that >>a bunch of things have to take notice of in order to behave >>securely, because that model of security is prone to springing >>leaks -- as happened in a big way when new-style classes were >>introduced. > > Right. Restricted mode currently uses both paradigms: you only have > access to the builtins that are given to you in the builtins dict > -- this is pure capability stuff, and IMO it works well -- and some > builtin operations behave differently when you're in restricted mode > -- this is the ACL stuff, and Samuele revealed serious holes in it.

What if instead of 'builtin behaves differently in restricted mode' we had 'restricted builtins contains a DIFFERENT builtin, that happens to have the same name'? That is, in addition to the ability to simply deny access to a specific builtin function or class, there was the ability to replace one before giving it to the restricted code.

Oh, there is, of course.

Sorry, I wasn't clear. There are a few operations that are not spelled as built-in function calls that have to be restricted. For example, every object supports getting obj.dict -- but in restricted mode you don't want to allow this. The Python source currently checks for "was I called from restricted mode" to deny such operations. The holes that Samuele revealed had to do with tricking unrestricted code into invoking unsafe things with arbitrary arguments controlled by the restricted code.

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

More information about the Python-Dev mailing list