Dear Zope community,
please excuse my ignorance, but I am asked from time to time how secure or insecure Zope actually is, and I always have to say that I actually don't know.
There are people claiming that Zope opens a system to quite some level, others claim the opposite.
Can someone please enlighten me and give me some details? Especially, are there some Zope products considered especially "insecure"?
Well, here's the way I read this. Let's say you're a system administrator and someone wants to add a service you've never heard of. Here's what you would ask to assess its security:
- Is there any way this service can grant root privileges? If so, are there adequate protections?
- Can this service do things to the server that are difficult to control, like fork bombs or lock starvation?
- Can this service be hijacked to do unexpected things on the network (like assist in a DDoS attack or relay spam)?
- Even if it can't hurt the server or other servers, does the service protect itself from vandalism, information theft, and DoS attempts?
- Have there been a lot of security vulnerability patches for this service?
I think this list is pretty comprehensive. I think if stock Zope provides satisfactory answers to all of these questions, we can legitimately call it secure.
First, even if you run Zope as root, Zope drops root privileges as soon as it can. By the time it accepts requests, it can no longer do anything as root. The Zope internal security model is fully confined to the limitations of the owner of the Zope process. So stock Zope is secure in this regard.
Second, certain features of modern kernels aren't quite mature, and if abused, these features can lead to a denial of service. Zope uses long-running Python threads, so it doesn't make much use of kernel services like forking and massive locking. (Other resources like RAM, CPU, and hard disk space are more mature and easier to control using ulimits, quotas, and partitions.) Stock Zope is secure in this regard.
Third, Zope is designed to be a self-contained network service. Other than the internal SMTP relay service, stock Zope doesn't have a way to access services on other servers. In a way, this is a missing feature, but it also makes Zope unattractive as a potential DDoS relay node. As for relaying spam, the SMTP relay service is protected by Zope's security model. Only trusted users can send email. So if Zope's security model is secure, stock Zope is secure in this regard too.
Fourth, Zope has its own security model independent of the system security that controls access to the Zope database, Python products, and the Python standard library. There have been mistakes in the internal security model before, but the mistakes only allowed already trusted users to do more than they should. I don't know of any security model breach ever that allowed untrusted or anonymous users to do something they shouldn't. And again, even if the internal security model is broken, Zope is still confined to the limitations of the owner of the process. So Zope is secure in this regard, as far as we know.
Fifth, it is true that many hotfixes have been released for Zope, but Zope hotfixes are really quite different from patches to other products. Patches to other products tend to fix system-level things like buffer overflows, root exploits, temporary file race conditions, etc. Zope hotfixes operate at a much higher level than that, fixing only things that Zope cares about. If a system administrator installed an old version of Zope but ignored all the hotfixes ever released for Zope, the system would still be safe and Zope would still be protected against attacks by anonymous users. The only vulnerability would involve trusted users who want to vandalize Zope. So even though there have been many hotfixes, they are irrelevant--Zope is still secure. (Unless you can't trust your trusted users, which is a different problem.)
So I think we can reliably say that stock Zope is secure. An insecure product, on the other hand, opens up many possibilities, but that ought to be the subject of a different discussion.
Shane
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
