[Zope] Security and resposability

[Chris McDonough]

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 )