Re: [Zope-dev] Re: Improvements for Zope2's security
Christian Heimes wrote at 2006-9-19 16:02 +0200: > ... >* As far as I understand the security system Zope2's can't protect >attributes and descriptors (properties) with >security.declarePrivate('attributename'). Since Zope 2.8, this is no longer true. You can protect simple type attributes and descriptors in the same way as methods. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Improvements for Zope2's security
On Tue, Sep 19, 2006 at 04:34:55PM +0200, Philipp von Weitershausen wrote: | >In general I preferre old and well tested security code over new | >security related code. Martjin, Phillip and all the other people are | >doing a great job with Five but well ... it's new code. New code tends | >to break because it is not as well tested as old code. | | There isn't much new in terms of security regarding what ZCML does in Five. In fact all it does is to map Zope 3 security directives to Zope 2 ClassSecurityInfo-style. | >* ZCML security declarations are great for Zope3 and Five classes | >because their default security policy is DENY unless explictly allowed. | | ZCML does NOT change the security policy of Zope 2. ZCML is just an | *spelling* of security declarations. So, it's not much new code at all. And in fact it has tests. | >* Comments like are adding a bad gut feeling ... | | is soemthing that's not in Zope 3 and I don't know what Sidnei | (who did the ZCML-Zope2-security integration) intended there. It's | certainly nothing that poses a security threat. We don't operate on bad | gut feelings. If you see definite problems with Five code, I'll be happy | to discuss them. I believe Zope 3 had at some point. It might not have it anymore those days. If I recall, the motivation was to be able to add the notion of 'deny by default' which exists in Zope 3. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Improvements for Zope2's security
Christian Heimes wrote: Zope's security declarations have to be called with a method *name* AS STRING. Developers are human beeings and human beeings tend to make small errors like typos. Or they forget to change the security declaration when they rename a method. Zope doesn't raise an error when a developer adds a security declaration for a non existing method. Have a look at the following example. It contains a tiny but devastating typo:: security.declarePrivate('chooseProtocol') def chooseProtocols(self, request): ... These kinds or errors are extremly hard to find and may lead to big security holes. By the way this example was taken from a well known and well tested Zope addon! THis problem is easily adressed when using ZCML security declarations + interfaces. Your decorator idea would also work. Issue 2 === Another way to introduce security breaches is to forget the InitializeClass() call. The call is responsable for applying the informations from a ClassSecurityInfo. Without the call all security settings made through security.declare* are useless. The good news is: Even if a developer forgets to call the method explictly in his code the function is called implictly. The implicit call was hard to find for me at first. I struggled with the code in OFS.Image because there is an import of InitializeClass but it is never called. Never the less the security informations are somehow merged automagically. After some digging I found the code that is responsible for the magic. It's ExtensionClass' __class_init__ magic and OFS.ObjectManager.ObjectManager.__class_init__ Now the bad news: The magic doesn't work under some conditions. For example if you class doesn't subclass ObjectManager or if you monkey patch a class with security info object you have to call InitializeClass explictly. The InitializeClass call is a big problem. I once discovered a big CMF security breach because of a missing InitializeClass call. Magic isn't a solution here, though. ZCML, for example, calls InitializeClass every time it changes the security declarations for a class. If you use ZCML, you're on the safe side. Issue 4 === Some methods shouldn't be callable from certain types of request methods. For example there is no need that the webdav DELETE and PROP* methods should be callable from an ordinary HTTP GET request. I don't want to go into details. Some people know why :) I have no idea how you want to distinguish HTTP and WebDAV requests. They're pretty much the same. But you're right, Zope allows too much. I'm not convinced this is a security responsibility though. I think in the long term we'll adopt a solution like in Zope 3: look up views based on the request type. Only a small subset is implemented. There are two methods in my patch to either whitelist or blacklist a request method. An older version of my patch contained even code to distinguish between request types (ftp, http, ftp, xml-rpc) but Jim told me in a private mail it's kind of YAGNI. I wonder what he meant by that. In Zope 3 we certainly do it. In general, I think a sane way to improve Zope's security system is to adopt certian Zope 3 idioms until we essentially are using Zope 3's security machinery, but probably with a Zope 2 specific security policy. I find that Zope 3's approach with security proxies is a *much* easier approach than manual guarded_getattr etc., and Zope 3's checkers are much more flexible than Zope 2's ClassSecurityInfo stuff. I personally think that efforts in improving Zope 2 security should primarily look at backporting useful features from Zope 3. That doesn't mean Zope 3 has to always have the right way of doing it, but at least changes in Zope 2 shouldn't go without an investigation of how Zope 3 does it. Philipp ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Improvements for Zope2's security
Hey Christian, welcome back! :) Christian Heimes wrote: Lennart Regebro schrieb: You have many good points in your list of troubles. Many of them are resolved by using security declarations through ZCML instead. It would be interesting to here your views on this. In general I preferre old and well tested security code over new security related code. Martjin, Phillip and all the other people are doing a great job with Five but well ... it's new code. New code tends to break because it is not as well tested as old code. There isn't much new in terms of security regarding what ZCML does in Five. Here is a list of my views and concerns about ZCML and Five security. Some or all of my points might be wrong. This is hazardous. We're about to spend serious time on discussions that may be pointless due to the lack of proper research... * ZCML security declarations are great for Zope3 and Five classes because their default security policy is DENY unless explictly allowed. ZCML does NOT change the security policy of Zope 2. ZCML is just an *spelling* of security declarations. So, it's not much new code at all. [NYV] The default object security of ClassSecurityInfo is declareObjectPrivate. [NYV] Where? In Five or in Zope 2? And what's the point? * But if you mix in subclasses of SimpleItem and others (Image, File and many more) you ar gaining their default security setting declareObjectPublic or declareObjectProtected(View)! It means that every method is availableunless explictly restricted. That's Zope 2 for you. This could lead to security breaches. IMO it is easier to find an unprotected method by reading code when the security declaration sits next to the method. A checker method for unit tests could be useful. Yup. * Comments like are adding a bad gut feeling ... is soemthing that's not in Zope 3 and I don't know what Sidnei (who did the ZCML-Zope2-security integration) intended there. It's certainly nothing that poses a security threat. We don't operate on bad gut feelings. If you see definite problems with Five code, I'll be happy to discuss them. * As far as I understand the security system Zope2's can't protect attributes and descriptors (properties) with security.declarePrivate('attributename'). The default object permission always wins. A ZCML directive that protects an attribute or descriptor can lead to false security assumptions. [NYV] Again, ZCML is just a different spelling of security.declare*, but one that can help you avoid typo problems (e.g. when you use interfaces). It cannot solve deeply rooted problems of Zope 2's security machienry and the confusion it may create. Developers using security.declarePrivate may just as well be misled as someone using ZCML. * A long time ago somebody has told me that Zope2's security works only for objects that subclass from ExtensionClass.Base or an Acquisition class. Is this still true or is it a false information? At least currently the Zope 2 security policy needs an acquisition context because it aq_acquires __roles__. I have some work in a local sandbox that will make the dependency on Acquisition-based classes go away. Philipp ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Improvements for Zope2's security
Lennart Regebro schrieb: > You have many good points in your list of troubles. Many of them are > resolved by using security declarations through ZCML instead. It would > be interesting to here your views on this. In general I preferre old and well tested security code over new security related code. Martjin, Phillip and all the other people are doing a great job with Five but well ... it's new code. New code tends to break because it is not as well tested as old code. Here is a list of my views and concerns about ZCML and Five security. Some or all of my points might be wrong. I had only one hour time to read code and I did no debugging or unit testing of my concerns. (NYV = not yet verified) * ZCML security declarations are great for Zope3 and Five classes because their default security policy is DENY unless explictly allowed. [NYV] The default object security of ClassSecurityInfo is declareObjectPrivate. [NYV] * But if you mix in subclasses of SimpleItem and others (Image, File and many more) you ar gaining their default security setting declareObjectPublic or declareObjectProtected(View)! It means that every method is availableunless explictly restricted. This could lead to security breaches. IMO it is easier to find an unprotected method by reading code when the security declaration sits next to the method. A checker method for unit tests could be useful. * Comments like are adding a bad gut feeling ... * As far as I understand the security system Zope2's can't protect attributes and descriptors (properties) with security.declarePrivate('attributename'). The default object permission always wins. A ZCML directive that protects an attribute or descriptor can lead to false security assumptions. [NYV] It is possible to protect attributes with different permissons by hooking into __allow_access_to_unprotected_subobjects__. The class var can be set to a bool (1 = public, 0 = private), a string (permission name), a dict (attribute name -> 0/1) or a callable. I have an idea how to protect descriptors and attributes based on some work from Sidney for Archetypes. * A long time ago somebody has told me that Zope2's security works only for objects that subclass from ExtensionClass.Base or an Acquisition class. Is this still true or is it a false information? Christian ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )