[Zope-dev] Request For Comments: SecurityJihad

Dieter Maurer dieter@handshake.de
Wed, 15 Aug 2001 22:32:10 +0200 (CEST)


Michael R. Bernstein writes:
 > .....
 > Older products that do not use declarative security at all should not
 > break, and will never need to use those declarations. Declarative
 > security was added in Zope 2.3, so not too many products have
 > incorporated it yet. Those that did, encountered the same problems as I,
 > and would probably be glad of the simplification, even if it means
 > making another release.
Not sure, I see big simplifications...

At least, I was aware that "SimpleItem" had the
"__allow_access_to_unprotected_subobjects__=1".
And I followed the Interfaces' example to always state
the permissions, unless I prefixed the name with a '_'
which indicates "private - do not use from outside".

 > > Most products would not want or need to set
 > > 
 > >      "__allow_access_to_unprotected_subobjects__= 0"
 > > 
 > > as was your primary concern.
 > 
 > Hmm. Well, I disagree somewhat. I think that product developers
 > generally are (or were) under the assumption that the default policy is
 > "deny unless allowed" and design their products accordingly.
At least, it does not apply to me.
 > Data that
 > otherwise would not be accessible to unauthorized users via DTML is
 > exposed, and unless the developer tests for this, they might never know.

I think, it would not be a problem, when
"__allow_access_to_unprotected_subobjects__=0" would
prevent ZPublisher from exposing methods without
explicit protection. You should go ahead with this.

But, you probably should not modify the "default" in
"SimpleItem" as older products might rely in this.

 > > I would not call a Jihad but provide a solution for the
 > > critical products and leave the rest alone.
 > 
 > Whether this mismatch is critical or not depends on the product in
 > question.
Yes, critical products should be changed.
There should be no need to touch uncritical ones.

 > I'm trying to leave as much alone as possible while eliminating the
 > cruft for current and future product developers. Accordingly, my
 > proposal now states that older products that do not use the declarative
 > security framework (added in Zope 2.3) should continue to work
 > unchanged.
I do not like the proposed distinction at all:

   new declarative security                --> strict control
   traditional (also declarative) security --> loose control

It also may break with inherited classes:

  If my new class uses declarative security but
  inherits from a class with the traditional security declarations,
  then your proposal would make my new class strict
  while the inherited class may require looser control.

 > I think it is very important that security for products be easy and
 > straightforward to add. If I may borrow a turn of phrase from Casey
 > Duncan, It should take effort to create an insecure product,
 > not the other way around.
Would

	security.declareDefaultAccess('private')

be too much effort to create a secure product?

In my view, it wouldn't.


Dieter