[Zope-dev] Request For Comments: SecurityJihad

[Michael R. Bernstein]

On 15 Aug 2001 22:32:10 +0200, Dieter Maurer wrote:
> 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".

Well, *I* wasn't aware at first of Item and SimpleItem overriding the
default policy. It's a *good* default policy. Security declarations
cannot (at this time) be made on simple attributes, only methods. If you
want to protect attributes from being accessed from DTML, you have to
either use yet another "magic" naming convention or re-override the
policy back to the default (Yuck). Although leading underscores are a
known convention from Python Modules, it's still a bit obscure for
python newbies, IMO. (disclaimer: I consider myself to be a Python
newbie, even though I've been using Zope for over two-and-a-half years).

Finally, if you're going to state all permissions explicitly anyway,
what's the point of having a default policy? You might as well simply
require that all methods must have a security declaration, and throw an
exception if they don't.

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

Ok, fair enough. It did apply to me, though, and I asked several times
on the list before someone gave me the right answer, even after several
developers had looked at my code. The common response was "Well, it
*should* work...".

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

Ah, so you are definitely in favor of changing the 'docstrings make
publishable' behaviour then.

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

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

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

> 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 would consider this to be correct behaviour.

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

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.
If the default policy is going to be changed to 'deny unless allowed'
(and that was clearly the intention of the declarative security
project), then it needs to be *changed*. I don't see another good
candidate for making that change over to the new default policy other
than at the line of 'uses the new declarative security'. 

You can't say that the default policy is 'deny unless allowed' if you
still have to do something extra to turn it on.

Michael Bernstein.