[Zope] Re: PythonMethods and import

[Evan Simpson]

I distinguish three levels of possible security failures, here:

1) Denial of service: Consumption of excessive CPU, memory, disk space, etc.
2) Improper object access: Bypassing permission/role security on ZODB contents.
3) OS-level access: Executing arbitrary code on the server.

For reasons I don't want to broadcast on a public mailing list, I'm not worrying too
hard about #1, yet.  Number 2 and *especially* #3 are showstoppers, though.  If
PythonMethods break security in either of those ways, they shouldn't be used except
by people willing to assume that level of risk.  If they break security without
people *knowing* that there's a risk, that's unacceptable.

That said, note that the import question is not PythonMethod-specific.
Scarywildunchained PythonMethods are inherently a huge security hole, and I
advertise that fact.  Standard PythonMethods don't allow generalized import, so the
issue there *should* be identical to the issue with DTML, namely, what can you
safely bring into the namespace through External Methods.

Robin Becker wrote:

> Ok I see we're getting more deeply into what can be imported and what
> can't. How can you snoop into another thread? As I understand it at
> present the PMs can only access their locals. If I can get access to any
> form of peek/poke I can certainly do nasty things. But can I do this
> with the re module? The sys module is certainly dangerous as is the
> thread module since it might allow us to use up all the threads. Since
> denial of service is possible with looping constructs any form of non
> resource limited thing is insecure. I'm fairly sure individual threads
> in Python aren't resource limited and unless Zope contains some kind of
> watchdog simple PMs are insecure. Importing re might make them more
> insecure by using up resources more rapidly (I believe certain regexps
> are very cpu intensive), but I don't think they change the quality of
> the insecurity.