[Zope-Coders] Re: [Zope-Checkins] CVS: Zope/lib/python/AccessControl - ZopeGuards.py:1.13

Ken Manheimer klm@zope.com
Tue, 17 Dec 2002 16:18:47 -0500 (EST)


I hope i'm not going off half-cocked, but this argument does not sound
good.

On Tue, 17 Dec 2002, Chris Withers wrote:

> Shane Hathaway wrote:
> 
> <snip examples>
> > There needs to be something that declares that a module is allowed to be 
> > imported, otherwise Zope opens up large unknowns.
> 
> Well indeed. BUT, how is a module supposed to say it's allowed to be imported?
> Answer: it makes security declarations.
>
> How does Zope find these declarations?
> Answer: by importing the module.

That's not the whole story.  A module need not make its own security
declarations - other modules can do so (using eg ModuleSecurityInfo).
So you can put something in your product to enable import of modules
not part of your product.
 
> What does Zope do if it fails to find the declaration?
> Answer: fail to import the module.

More like, "refuse to import the module".  There **must** be some way
to prevent import of modules, and it must be a deliberate-allow
policy, rather than deliberate-deny.

It's very appealing to skimp on security until you're the one that's
burned.  However, we're *all* burned if we compromise on zope
security.  I haven't been following this issue in complete detail, but
it sounds like you're advocating a fix that compromises security for
the sake of convenience, particularly if using ModuleSecurityInfo
serves as i suggest.  Even if it's not just convenience, and a feature
is blocked, that's no excuse to compromise security.

-- 
Ken
klm@zope.com