[Zope-dev] Request For Comments: SecurityJihad

[Michael R. Bernstein]

On 14 Aug 2001 21:02:53 +0200, Dieter Maurer wrote:
>
> Michael R. Bernstein writes:
>  >
>  > So I'm asking the product authors on the list if that breakage is
>  > acceptable, provided they can re-activate the "magic" by doing:
>  > 
>  > security.useMagicMethodNames("yes")
>  > security.docstringsMakeObjectsPublishable("yes")
>
> What about the other way round:
> 
>   If you want stricter security on a product, then add a declaration
> 
>      security.useStrictSecurity("yes")

I'm unhappy with the idea that Zope products would default to lower
security by design.

> Many useful products are no longer actively maintained.
> When you require special declarations, they may become unusable.

Only products that use the declarative security framework should ever
need to use those special declarations, and then only if they also
happen to depend on the current behaviour of ZPublisher regarding
docstrings, or on the behaviour of the class-loader regarding special
method names.

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.

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

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

Thanks for the feedback!

Michael Bernstein.