[Zope-dev] Request For Comments: SecurityJihad

Michael R. Bernstein webmaven@lvcm.com
16 Aug 2001 15:17:01 -0700


On 16 Aug 2001 22:54:16 +0200, Dieter Maurer wrote:
> 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.

Ah, so this aspect of product development could be considered confusing
to experienced Python programmers who are new to Zope as well?

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

The mechanism is essentially the same, but consider that one of the
(clearly stated) underlying assumptions of the new declarative security
is that the default policy is 'deny if not allowed'. This assumption is
violated in the following ways:

 - docstrings make methods traversable unless you do __roles__=0

 - Item and SimpleItem override the default to a policy of 'allow unless
denied', which must then be re-overridden

 - methods that begin with 'manage_' are treated specially.

All three of those things violate the default policy of 'deny unless
allowed'.

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

Ok.

>   *  roles provided finer grained control
> >  > ....
>   *  never saw any special handling for "manage_*" methods.

You mean that you've never seen it demonstrated? I think you said that
you always add explicit security directives anyway. The special handling
of 'manage_' methods only shows up if the method does not have an
explicit security statement.

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

Ok.

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

Ah. I see. Item and SimpleItem will not be changed acording to my
proposal. classes that derive from Item and Simpleitem (or other classes
derived from them) will continue to require either
'__allow_access_to_unprotected_subobjects__ = 0' or
'security.setDefaultAccess("deny")'. This change was made for just the
backward compatibility reasons that you cite.Two new classes (SecureItem
and SimpleSecureItem, or something similar) will have a different
default policy for this purpose, and will not require derived classes to
re-override the policy.

I'm sorry I seemed to imply that an inherited setting of 'allow unless
denied' would be overridden by the use of declarative security. It won't
be.

Only the docstring and 'manage_' behaviours are intended to be switched
off by default through the use of the new declarative security.

For those products that currently rely on the docstring and 'manage_'
behaviours *and* use declarative security, a way of turning those
behaviours back on will be provided, eg:

- security.docstringsMakePublishable("yes") 

- security.manageMethodNamesAreSpecial("yes")

Now, I would expect future releases of Zope to *eventually* switch from
Item and SimpleItem to their more secure versions for all core
components, but that is for another proposal.

>  > > Would
>  > > 
>  > > 	security.declareDefaultAccess('private')
>  > > 
>  > > be too much effort to create a secure product?
>  > 
>  > 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.

What I would like to see:

Classes that subclass from Item or SimpleItem (or other derived classes)
will require an explicit statement (security.setDefaultPolicy("deny") )
to set a stricter policy.

Two new classes will be provided to make this step unneccessary for
classes derived from them.

Docstring behaviour is switched off by default when the new declarative
security is used, since it violates the default policy.

'manage_' method behaviour is switched off by default when the new
declarative security is used, since it violates the default policy.

Products that do not use declarative security do not have these two
behaviours turned off.

Both of these behaviours can be turned back on for transitional products
(ones that use declarative security and depend on the "magic") by the
developer using simple statements.

How does that sound?