Security and resposability
I'm in some troubles with two problems: one is concerning session and the other security. The session problem is connected with references maintaned in items (specifically dictionary) stored in a session to the original objects. The list helped me to understand that copy() and deepcopy() exist: this could have solved the problem. However, the Python module copy is not loadable for security resons. Some time ago I had the necessity to evaluate a string, that could be done using eval(). However, eval() is not usable for security resons. Both situations can be overidden using an External Method "safe_eval" (as pointed out by Dieter Maurer in an answer to my thread dictionary definition and strings on 4 Apr 2002). Now, I would have no technical difficulties doing that, but, for a "political" decision of the institution using the product, everything developed must be usable with the current "standard" version of Zope, without modifying even a comma on the original downloaded files. This means no External Method "safe_eval". Now, my question is: why limit the usage of methods like copy(), deepcopy() and eval()? The usual answer is to rise the security treshold. OK, but this is also an "a priori" limitation of developer responsability. I believe that I understand the troubles an evaluation of a client query could produce. But can some guru explain to me how an hacker could produce crashes or some other sever damages if I use such methods to evaluate an internally generated string or deepcopying an internally generated dictionary? Sorry for the long message. p.t.
Hi, With regards to the first (sessioning) problem, it seems that you've got it more or less solved as you know what needs to be done. With regards to the restrictions on certain Python functions within Zope, eval is definitely a no-no (as you could cause code to be executed that you otherwise would not have privileges to execute, perhaps something like "eval('context.Control_Panel.manage_shutdown()')". But I'm afraid I can't actually think up a scenario where deepcopy or copy would cause problems. That said, I wasnt the one who reviewed which functions were accessible from within Python Scripts and DTML/TAL, I'm sure there's at least a nominally good reason. ;-) With regards to your company's policy of not "changing" Zope... this is a fairly arbitrary policy (IMHO). Zope is a framework that is meant to be extended. You extend it with Python Scripts, DTML Methods, Python Products, and External Methods, etc. You are not changing Zope when you write an external method, you are using it in the way it is meant to be used. - C On Sat, 2002-06-15 at 14:45, p.t. wrote:
I'm in some troubles with two problems: one is concerning session and the other security.
The session problem is connected with references maintaned in items (specifically dictionary) stored in a session to the original objects. The list helped me to understand that copy() and deepcopy() exist: this could have solved the problem. However, the Python module copy is not loadable for security resons.
Some time ago I had the necessity to evaluate a string, that could be done using eval(). However, eval() is not usable for security resons. Both situations can be overidden using an External Method "safe_eval" (as pointed out by Dieter Maurer in an answer to my thread dictionary definition and strings on 4 Apr 2002).
Now, I would have no technical difficulties doing that, but, for a "political" decision of the institution using the product, everything developed must be usable with the current "standard" version of Zope, without modifying even a comma on the original downloaded files. This means no External Method "safe_eval".
Now, my question is: why limit the usage of methods like copy(), deepcopy() and eval()? The usual answer is to rise the security treshold. OK, but this is also an "a priori" limitation of developer responsability. I believe that I understand the troubles an evaluation of a client query could produce. But can some guru explain to me how an hacker could produce crashes or some other sever damages if I use such methods to evaluate an internally generated string or deepcopying an internally generated dictionary? Sorry for the long message. p.t.
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Chris McDonough writes:
With regards to the restrictions on certain Python functions within Zope, eval is definitely a no-no (as you could cause code to be executed that you otherwise would not have privileges to execute, perhaps something like "eval('context.Control_Panel.manage_shutdown()')". But Zope could expose safe versions of a set of urgently missing functions, example:
has_attribute(obj,attr) (defined as "hasattr(aq_base(obj),attr)") safe_eval (implemented the same way as evaluation in DTML or Page Template)
But I'm afraid I can't actually think up a scenario where deepcopy or copy would cause problems. What, when I try to "deepcopy" the application root. I can imagine that this operation is quite a big load for a large Zope site.
Dieter
p.t. writes:
... Now, I would have no technical difficulties doing that, but, for a "political" decision of the institution using the product, everything developed must be usable with the current "standard" version of Zope, without modifying even a comma on the original downloaded files. This means no External Method "safe_eval". But you do not modify the original downloaded files when you use an External Method. The only thing, you need to do for a different Zope distribution/installation is to link/move your Extensions Folder into the installations "INSTANCE_HOME".
I would press the institution to think about the reasons for this policy. Dieter
participants (3)
-
Chris McDonough -
Dieter Maurer -
p.t.