Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Zope: Dev

Zope 4 publisher/traversal, sprint topic

 

 

Zope dev RSS feed   Index | Next | Previous | View Threaded


leonardo at nexedi

Oct 27, 2011, 6:34 AM

Post #1 of 7 (386 views)
Permalink
Zope 4 publisher/traversal, sprint topic

Hi,

Sorry for the cross-post, but I'd like to talk about a possible sprint
topic for the next DZUG sprint[1], and invite myself to it :-)

After the last two rather serious security issues that were recently
patched in the Zope2 code base, it is increasingly clear to me that,
differently than what Hanno reported some time ago, it's not so much
the ZMI that represents a huge security liability in the Zope
codebase, but it's actually the way the current publisher happily
traverses any attribute and publishes any method with docstring by
default.

The ZMI, of course, has its problems (ugly in appearance and even
uglier in code), and I agree with Hanno on most everything he has to
say about it, but I'd like to propose we start, for Zope 4, by
tackling the potential security liability that is the Zope publisher
itself, and the fact that it makes it easy to open up large security
holes if you're not paying attention.

I'd like to propose that publishing traversal in Zope 4 would, by
default only traverse based on __getitem__ (not attribute lookup). For
a minimum of backward compatibility, it could perhaps do a single
traversal on getattr, and only after it has exhausted __getitem__
traversal.

After this, if the traversal found something, it would only be
published if there is an explicit indication of intention that the
object in question is supposed to be published. Otherwise, raise a
NotFound, as if the traversal had failed.

One example of an explicit demonstration of intent is, for example, if
it provides an IPublishable interface (I just made that up, other
names can be considered).

Taking a suggestion from Shane, we could have convenient decorators
for people who wants to explicitly publish class methods. They could
dynamically create ZTK views with the same name as the function that
they wrap and allow (or perhaps enable by default) some form of CSRF
protection.

To ease code migration, we could consider that the InitializeClass
call provides the same effect as the above decorator. This would allow
large amounts of previously existing code to work without recoding,
while at the same time avoiding the security trap of forgetting to
call InitializeClass and thus exposing unintented methods. It could
even remove the need for the "single getattr traversal" compatibility
above.

On top of that, if InitializeClass register these views to a specific
ZTK "skin", it would make it possible to disable them by default,
unless that specific skin is in effect, which would alleviate what
Hanno described as "running phpMyAdmin accessible to the world with
the same credentials and on the same domain as the rest of your
application".

Anyway, I think the above is on-topic for the next DZUG sprint and I'd
like to work on it there.

So, even if the sprint is supposed to be in German, and I don't speak
a word of it, can I attend?

[1] http://www.zope.de/community/veranstaltungen/3.-dzug-sprint-2011-zmi
, translation at:
http://translate.google.com/translate?hl=en&sl=auto&tl=en&u=http%3A%2F%2Fwww.zope.de%2Fcommunity%2Fveranstaltungen%2F3.-dzug-sprint-2011-zmi

Cheers,

Leo
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )


regebro at gmail

Oct 27, 2011, 7:07 AM

Post #2 of 7 (383 views)
Permalink
Re: Zope 4 publisher/traversal, sprint topic [In reply to]

Do we really have to call it Zope 4? :-)

On Thu, Oct 27, 2011 at 15:34, Leonardo Rochael Almeida
<leonardo [at] nexedi> wrote:
> Hi,
>
> Sorry for the cross-post, but I'd like to talk about a possible sprint
> topic for the next DZUG sprint[1], and invite myself to it :-)
>
> After the last two rather serious security issues that were recently
> patched in the Zope2 code base, it is increasingly clear to me that,
> differently than what Hanno reported some time ago, it's not so much
> the ZMI that represents a huge security liability in the Zope
> codebase, but it's actually the way the current publisher happily
> traverses any attribute and publishes any method with docstring by
> default.
>
> The ZMI, of course, has its problems (ugly in appearance and even
> uglier in code), and I agree with Hanno on most everything he has to
> say about it, but I'd like to propose we start, for Zope 4, by
> tackling the potential security liability that is the Zope publisher
> itself, and the fact that it makes it easy to open up large security
> holes if you're not paying attention.
>
> I'd like to propose that publishing traversal in Zope 4 would, by
> default only traverse based on __getitem__ (not attribute lookup). For
> a minimum of backward compatibility, it could perhaps do a single
> traversal on getattr, and only after it has exhausted __getitem__
> traversal.
>
> After this, if the traversal found something, it would only be
> published if there is an explicit indication of intention that the
> object in question is supposed to be published. Otherwise, raise a
> NotFound, as if the traversal had failed.
>
> One example of an explicit demonstration of intent is, for example, if
> it provides an IPublishable interface (I just made that up, other
> names can be considered).
>
> Taking a suggestion from Shane, we could have convenient decorators
> for people who wants to explicitly publish class methods. They could
> dynamically create ZTK views with the same name as the function that
> they wrap and allow (or perhaps enable by default) some form of CSRF
> protection.
>
> To ease code migration, we could consider that the InitializeClass
> call provides the same effect as the above decorator. This would allow
> large amounts of previously existing code to work without recoding,
> while at the same time avoiding the security trap of forgetting to
> call InitializeClass and thus exposing unintented methods. It could
> even remove the need for the "single getattr traversal" compatibility
> above.
>
> On top of that, if InitializeClass register these views to a specific
> ZTK "skin", it would make it possible to disable them by default,
> unless that specific skin is in effect, which would alleviate what
> Hanno described as "running phpMyAdmin accessible to the world with
> the same credentials and on the same domain as the rest of your
> application".
>
> Anyway, I think the above is on-topic for the next DZUG sprint and I'd
> like to work on it there.
>
> So, even if the sprint is supposed to be in German, and I don't speak
> a word of it, can I attend?
>
> [1] http://www.zope.de/community/veranstaltungen/3.-dzug-sprint-2011-zmi
> , translation at:
> http://translate.google.com/translate?hl=en&sl=auto&tl=en&u=http%3A%2F%2Fwww.zope.de%2Fcommunity%2Fveranstaltungen%2F3.-dzug-sprint-2011-zmi
>
> Cheers,
>
> Leo
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev [at] zope
> https://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists -
>  https://mail.zope.org/mailman/listinfo/zope-announce
>  https://mail.zope.org/mailman/listinfo/zope )
>
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )


jens at dataflake

Oct 27, 2011, 8:47 AM

Post #3 of 7 (381 views)
Permalink
Re: Zope 4 publisher/traversal, sprint topic [In reply to]

On Oct 27, 2011, at 16:07 , Lennart Regebro wrote:

> Do we really have to call it Zope 4? :-)

Yes.

jens



_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )


l at lrowe

Oct 27, 2011, 12:25 PM

Post #4 of 7 (383 views)
Permalink
Re: Zope 4 publisher/traversal, sprint topic [In reply to]

On 27 October 2011 14:34, Leonardo Rochael Almeida <leonardo [at] nexedi> wrote:
> Hi,
>
> Sorry for the cross-post, but I'd like to talk about a possible sprint
> topic for the next DZUG sprint[1], and invite myself to it :-)

We'll also be sprinting on Zope 4 before the Plone conference this
coming Monday, Tuesday, Wednesday. There are a couple of places left,
so if anyone else can make it do let me know.
http://coactivate.org/projects/san-francisco-zope-sprint

Laurence
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )


tseaver at palladion

Oct 27, 2011, 12:37 PM

Post #5 of 7 (384 views)
Permalink
Re: Zope 4 publisher/traversal, sprint topic [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/27/2011 10:07 AM, Lennart Regebro wrote:
> Do we really have to call it Zope 4? :-)

That was the general consensus back in June: it is a BBB-incompatible
release, not truly incremental to 2.12 / 2.13. Calling it "3.0"
obviously unworkable.


Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver [at] palladion
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6psv4ACgkQ+gerLs4ltQ4NXgCfYAR5qskOGdYJ0OvGSe3tRD5p
XZAAoMuRSgH1EX0Pu/z9l89nBZEtPnqS
=skzw
-----END PGP SIGNATURE-----

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )


y.2011 at wcm-solutions

Oct 28, 2011, 12:46 AM

Post #6 of 7 (382 views)
Permalink
Re: Zope 4 publisher/traversal, sprint topic [In reply to]

Hi!


Leonardo Rochael Almeida wrote:
> After the last two rather serious security issues that were recently
> patched in the Zope2 code base, it is increasingly clear to me that,
> differently than what Hanno reported some time ago, it's not so much
> the ZMI that represents a huge security liability in the Zope
> codebase, but it's actually the way the current publisher happily
> traverses any attribute and publishes any method with docstring by
> default.

Is that the fault of the publisher? AFAICT the biggest security problem
of Zope2 is this line in OFS.SimpleItem.Item:

# Allow (reluctantly) access to unprotected attributes
__allow_access_to_unprotected_subobjects__=1

I'm not familiar with the details of the first hotfix, but the second
one wouldn't have been necessary without that line.

I propose to remove that line in Zope 4 and to add explicit security
declarations where ever needed. The first part is easy, the second part
a lot of work for many people.


Cheers,

Yuppie
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )


chris at simplistix

Oct 28, 2011, 1:39 AM

Post #7 of 7 (382 views)
Permalink
Re: Zope 4 publisher/traversal, sprint topic [In reply to]

On 28/10/2011 08:46, yuppie wrote:
> Is that the fault of the publisher? AFAICT the biggest security problem
> of Zope2 is this line in OFS.SimpleItem.Item:
>
> # Allow (reluctantly) access to unprotected attributes
> __allow_access_to_unprotected_subobjects__=1
>
> I'm not familiar with the details of the first hotfix, but the second
> one wouldn't have been necessary without that line.

Yep, that's what should have been done in the first place.

cheers,

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Zope dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.