Python methods look really nice however why remove the use of import. I guess this is a security hazard and allows access to the filesystem but it also allows the use of many very usefull packages that to use mean the messyness of creating external methods.
"Jay, Dylan" wrote:
Python methods look really nice however why remove the use of import. I guess this is a security hazard and allows access to the filesystem but it also allows the use of many very usefull packages that to use mean the messyness of creating external methods.
Evan's plan is to add 'import' again later, actually. But it takes a while thinking through the security considerations. Regards, Martijn
----- Original Message ----- From: Jay, Dylan <djay@lucent.com>
Python methods look really nice however why remove the use of import. I guess this is a security hazard and allows access to the filesystem but it also allows the use of many very usefull packages that to use mean the messyness of creating external methods.
Funny you should mention that! <wink>. I have a version for my personal use with unlimited import enabled for just this reason. I'm considering giving PythonMethods a permission (given to *no one* by default) which would allow this feature. That said, I'm not 100% sure exactly how import will work in the general case. Right now, I'm tentatively thinking of having a magical root 'package' called Zope, with which you could write: from Zope.folder1.folder2 import doc1 to get doc1 from folder2 from folder1 in the root of the ZODB, while only privileged users could perform a bare 'import frotz' to access 'real' packages and modules. Sound good?
Evan Simpson wrote:
----- Original Message ----- From: Jay, Dylan <djay@lucent.com>
Python methods look really nice however why remove the use of import. I guess this is a security hazard and allows access to the filesystem but it also allows the use of many very usefull packages that to use mean the messyness of creating external methods.
Funny you should mention that! <wink>. I have a version for my personal use with unlimited import enabled for just this reason.
Any way one could get a copy of that verson to play with ? :-) Bill Anderson
Bill Anderson wrote:
Evan Simpson wrote:
----- Original Message ----- From: Jay, Dylan <djay@lucent.com>
Python methods look really nice however why remove the use of import. I guess this is a security hazard and allows access to the filesystem but it also allows the use of many very usefull packages that to use mean the messyness of creating external methods.
Funny you should mention that! <wink>. I have a version for my personal use with unlimited import enabled for just this reason.
Any way one could get a copy of that verson to play with ? :-)
You want scarywildunchained PythonMethods? Sign this waiver, please. It says that if you use what I'm about to tell you on your site, you agree that I can't be held responsible for anything that may occur, up to and including Weird Al Yankovic stuffing your server with gerbils and making you program in Intercal on a Commodore PET. Thank you. Download the latest (0.1.1 as of this writing) PythonMethods, install it, and append the following lines to Guarded.py: if "you want completely unsecure, dangerous PMs" and "a classname that lies": from zbytecodehacks.VSExec import CodeBlock, Printing class GuardedBlock(CodeBlock): Mungers = [Printing] then find the one-and-only call to UntupleFunction in PythonMethod.py, and replace "safefuncs.__class__.__dict__" with "__builtins__". Restart Zope and watch the sparks fly.
Evan Simpson wrote:
Bill Anderson wrote:
Evan Simpson wrote:
...
Funny you should mention that! <wink>. I have a version for my personal use with unlimited import enabled for just this reason.
Any way one could get a copy of that verson to play with ? :-)
You want scarywildunchained PythonMethods? Sign this waiver, please. It says that if you use what I'm about to tell you on your site, you agree that I can't be held responsible for anything that may occur, up to and including Weird Al Yankovic stuffing your server with gerbils and making you program in Intercal on a Commodore PET.
Hey, he puts on a damned fun concert! :-)
Restart Zope and watch the sparks fly. Thanks, I am now donning my goggles :-)
Bill
In article <37DAE0BA.3AFC13B@4-am.com>, Evan Simpson <evan@4-am.com> writes
Bill Anderson wrote:
Evan Simpson wrote:
----- Original Message ----- From: Jay, Dylan <djay@lucent.com>
Python methods look really nice however why remove the use of import. I guess this is a security hazard and allows access to the filesystem but it also allows the use of many very usefull packages that to use mean the messyness of creating external methods.
Funny you should mention that! <wink>. I have a version for my personal use with unlimited import enabled for just this reason.
Any way one could get a copy of that verson to play with ? :-)
You want scarywildunchained PythonMethods? Sign this waiver, please. It says that if you use what I'm about to tell you on your site, you agree that I can't be held responsible for anything that may occur, up to and including Weird Al Yankovic stuffing your server with gerbils and making you program in Intercal on a Commodore PET. Thank you.
Download the latest (0.1.1 as of this writing) PythonMethods, install it, and append the following lines to Guarded.py:
if "you want completely unsecure, dangerous PMs" and "a classname that lies": from zbytecodehacks.VSExec import CodeBlock, Printing class GuardedBlock(CodeBlock): Mungers = [Printing]
then find the one-and-only call to UntupleFunction in PythonMethod.py, and replace "safefuncs.__class__.__dict__" with "__builtins__".
Restart Zope and watch the sparks fly.
... Couldn't this and similar things be done as a property setting on the method. The you could have a proxy security to allow various degrees of un-safeness rather than just hack the code for all people. So really safe people could open files on the server etc others could do regexps etc etc. -- Robin Becker
Robin Becker wrote:
Couldn't this and similar things be done as a property setting on the method. The you could have a proxy security to allow various degrees of un-safeness rather than just hack the code for all people. So really safe people could open files on the server etc others could do regexps etc etc.
Well... Sort of. I mean, yes, obviously this can be done, but there's a problem; Once *anyone* is allowed access to unsecure PythonMethod you've got a fairly large security risk going unless you routinely manage your server through https. Suppose someone snoops your management sessions and grabs the username/password you use for site administration. Normally, this lets them destroy or subvert the contents of your ZODB, but that's all. With scarywildunchained PythonMethods in the picture, they now have full access to your system as 'nobody', or whatever you run Zope under. On Windows, at least, this could be effectively root access. This *can* be made secure (I think) by routing all management through an SSL-enabled server and shutting off Zope2's other port access methods, but it's not secure by *default*, which is a concern. The upshot of all this is that I'll probably make unsecure PythonMethods an option, but not through the web-interface. I'll probably make it a switch in the source code, down in a broom closet in the basement with a sign on the door saying "Beware of the Leopard". and-don't-forget-the-toe-gremlins-ly y'rs Evan Simpson
In article <37DE5A9A.3B5EBBA0@4-am.com>, Evan Simpson <evan@4-am.com> writes
Robin Becker wrote:
Couldn't this and similar things be done as a property setting on the method. The you could have a proxy security to allow various degrees of un-safeness rather than just hack the code for all people. So really safe people could open files on the server etc others could do regexps etc etc.
Well... Sort of. I mean, yes, obviously this can be done, but there's a problem; Once *anyone* is allowed access to unsecure PythonMethod you've got a fairly large security risk going unless you routinely manage your server through https.
Suppose someone snoops your management sessions and grabs the username/password you use for site administration. Normally, this lets them destroy or subvert the contents of your ZODB, but that's all. With scarywildunchained PythonMethods in the picture, they now have full access to your system as 'nobody', or whatever you run Zope under. On Windows, at least, this could be effectively root access.
This *can* be made secure (I think) by routing all management through an SSL- enabled server and shutting off Zope2's other port access methods, but it's not secure by *default*, which is a concern.
The upshot of all this is that I'll probably make unsecure PythonMethods an option, but not through the web-interface. I'll probably make it a switch in the source code, down in a broom closet in the basement with a sign on the door saying "Beware of the Leopard".
and-don't-forget-the-toe-gremlins-ly y'rs Evan Simpson ... Ok I see we're getting more deeply into what can be imported and what can't. How can you snoop into another thread? As I understand it at present the PMs can only access their locals. If I can get access to any form of peek/poke I can certainly do nasty things. But can I do this with the re module? The sys module is certainly dangerous as is the thread module since it might allow us to use up all the threads. Since denial of service is possible with looping constructs any form of non resource limited thing is insecure. I'm fairly sure individual threads in Python aren't resource limited and unless Zope contains some kind of watchdog simple PMs are insecure. Importing re might make them more insecure by using up resources more rapidly (I believe certain regexps are very cpu intensive), but I don't think they change the quality of the insecurity. -- Robin Becker
I distinguish three levels of possible security failures, here: 1) Denial of service: Consumption of excessive CPU, memory, disk space, etc. 2) Improper object access: Bypassing permission/role security on ZODB contents. 3) OS-level access: Executing arbitrary code on the server. For reasons I don't want to broadcast on a public mailing list, I'm not worrying too hard about #1, yet. Number 2 and *especially* #3 are showstoppers, though. If PythonMethods break security in either of those ways, they shouldn't be used except by people willing to assume that level of risk. If they break security without people *knowing* that there's a risk, that's unacceptable. That said, note that the import question is not PythonMethod-specific. Scarywildunchained PythonMethods are inherently a huge security hole, and I advertise that fact. Standard PythonMethods don't allow generalized import, so the issue there *should* be identical to the issue with DTML, namely, what can you safely bring into the namespace through External Methods. Robin Becker wrote:
Ok I see we're getting more deeply into what can be imported and what can't. How can you snoop into another thread? As I understand it at present the PMs can only access their locals. If I can get access to any form of peek/poke I can certainly do nasty things. But can I do this with the re module? The sys module is certainly dangerous as is the thread module since it might allow us to use up all the threads. Since denial of service is possible with looping constructs any form of non resource limited thing is insecure. I'm fairly sure individual threads in Python aren't resource limited and unless Zope contains some kind of watchdog simple PMs are insecure. Importing re might make them more insecure by using up resources more rapidly (I believe certain regexps are very cpu intensive), but I don't think they change the quality of the insecurity.
participants (6)
-
Bill Anderson -
Evan Simpson -
Evan Simpson -
Jay, Dylan -
Martijn Faassen -
Robin Becker