[Zope-dev] Request For Comments: SecurityJihad

[Dieter Maurer]

Michael R. Bernstein writes:
 > Although leading underscores are a
 > known convention from Python Modules, it's still a bit obscure for
 > python newbies.
In fact, Python has only a weak policy towards privacy of objects
starting with '_': they are not imported by "from xxx import *";
nothing else is special about them.
It is Zope that much more strictly enforces the privacy policy.

 > ....
 > > 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.
 > 
 > Ah, so you are definitely in favor of changing the 'docstrings make
 > publishable' behaviour then.
If I explicitely stated "__allow_...__=0", yes.


 > > But, you probably should not modify the "default" in
 > > "SimpleItem" as older products might rely in this.
 > 
 > The latest version of the proposal does not change Item or SimpleItem,
 > but instead provides alternative base classes.
Good.

 > >  > > 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.
 > 
 > Agreed.
Fine.

 > ....
 > > I do not like the proposed distinction at all:
 > > 
 > >    new declarative security                --> strict control
 > >    traditional (also declarative) security --> loose control
 > 
 > If by 'loose control' you mean that the default policy changes to 'deny
 > unless allowed', then where would you propose making the distinction?
 > 
 > My proposal is basically trying to eliminate the confusing overlap
 > between the old and new security declarations, and they're underlying
 > assumptions.
I do not see a confusing overlap...

Formerly, I used "__ac_permissions__= <declarations>",
and "XXXX__roles__= <public, private>"

Now, I use:

     security= ClassSecurityInfo()
     ....
     security.declare...(...)

The new way is more consistent, clearer and better distributable.
But it is essentially the same mechanism.


 > I find that the use of the new Declarative Security
 > framework provides a convenient dividing line between the old
 > assumptions (docstrings make publishable, 'manage_' methods are special,
 > allow if not denied), and the new assumptions (no implied security
 > implications for method names or docstrings, policy is 'deny unless
 > allowed'). It's this confusion that leads to insecure products.
I have never seen it this way (and do not do it now):

  *  docstrings where a necessary requirement for being published

     I never viewed this as a good policy, as docstrings have
     nothing to do with being publishable.
     Even things that are private should have a docstring...

  *  roles provided finer grained control

  *  never saw any special handling for "manage_*" methods.

It is definitely a bug that ZPublisher is ready to publish unprotected
objects even if no "__allow_access_..." allows it.
Thus, I do not argue about this.

I only argue about removing the "__allow_access_..." from
SimpleItem.Item.
There was a reason to put it in there: without it, lots of
instability/breakage would have occured.
The same reason still applies.
A product must be carefully designed to function correctly
in a world with "deny unless explicitely allowed".
Many products are not yet designed that way whether they use
the new or the old security declarations.
 
 > ....
 > > Would
 > > 
 > > 	security.declareDefaultAccess('private')
 > > 
 > > be too much effort to create a secure product?
 > > 
 > > In my view, it wouldn't.
 > 
 > Mmm. I guess it's not the effort (as in work) of adding a simple
 > declaration like this, so much as the fact that this implies that the
 > default policy will continue to be 'allow if not denied' going forward.
That's what I would like to see:

   An explicite way that a product developper can state,
   I am interested in the strict security and have tested for it.
   Products that do not have that statement are old, but should
   nevertheless work.

Whether I use the new or old syntax for security declarations
should not be relevant.



Dieter