RE: open == file considered harmful (Re: [Python-Dev] RE: rexec.pyunuseable)
Michael Chermside
Greg:
In light of this, it may have been a serious mistake to unify the 'file' type and the 'open' function. Is it too late to back out of that decision?
Guido:
I think so.
I disagree. Right now, having access to a class object basically gives one the ability to create new objects of that type. I think that's just fine... and I don't mind applying it to the file object. I'd think that the thing to do with untrusted code is to deny it access to the 'file' type object, thus denying it the ability to create new 'file's directly.
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. The spirit behind my suggestion was to start thinking about ways in which functionality could be separated out so that this kind of special-casing for security purposes isn't needed. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
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.
The spirit behind my suggestion was to start thinking about ways in which functionality could be separated out so that this kind of special-casing for security purposes isn't needed.
Right. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
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. Regards, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan@email.com | Mobile: +61 409 573 268
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/)
Nick Coghlan
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 wouldn't solve the file problem, because if the restricted code ever got hold of a file object created by unrestricted code, it would have access to the "real" file class which can open any file. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
participants (3)
-
Greg Ewing -
Guido van Rossum -
Nick Coghlan