[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 !--deny attributes=baz /-- !-- XXX not yet
supported -- 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 )
[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 !--deny attributes=baz /-- !-- XXX not yet
supported -- are adding a bad gut feeling ...
deny / 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
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 )
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 !--deny attributes=baz /-- !-- XXX not yet | supported -- are adding a bad gut feeling ... | | deny / 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 deny / 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 )
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 )
[Zope-dev] buildbot failure in Zope branches 2.9 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope branches 2.9 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 7729 Blamelist: alecm,ctheune,fdrake,jim,jukart,srichter BUILD FAILED: failed test sincerely, -The Buildbot ___ 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] buildbot failure in Zope branches 2.9 2.4 Windows 2000 zc-bbwin2
The Buildbot has detected a failed build of Zope branches 2.9 2.4 Windows 2000 zc-bbwin2. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 7729 Blamelist: alecm,ctheune,fdrake,jim,jukart,srichter BUILD FAILED: failed compile sincerely, -The Buildbot ___ 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] buildbot failure in Zope branches 2.10 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope branches 2.10 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 7730 Blamelist: alecm,ctheune,fdrake,flox,jim,jukart,rogerineichen,shh,srichter BUILD FAILED: failed test sincerely, -The Buildbot ___ 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 )
