It turns out that OpenACS 5.1 was shipping with a default setting in the parameters section that allow any sort of HTML to be let through the security filters (to remove this, take out the *). This makes it trivial to completely take over an OpenACS server. I believe I could root a box in about 10 minutes with this security hole.
My basic argument is that the core of OpenACS should be secure by default, and that any packages that are insecure by design should be clearly marked as insecure.
Lars agreed that security was important, but thought that we too often sacrifice usability to obscure security issues. And he pointed out what a large usability problem our security filters have been in the past. Hopefully I've summed up your argument well, Lars?
In any case, I think our discussion (see http://openacs.org/irc/log/2004-05-26) brings up a larger issue of a security policy for OpenACS.
Perhaps we need both a security policy and some usability guidelines. To some extent, the conflict between usability and security can be alleviated by careful design, but it typically takes a lot more work to do so.
I personally would like to see our code held up to very high standards for both usability and security. But if we don't clarify what those standards are, and if they're worthwhile or not, we'll all have our own individual standards and no coherent strategy for OpenACS.
Any thoughts on this?
My proposal would be:
1) OpenACS *core* will be as secure as possible by default. Any changes that introduce a potential security hole have to be TIPped.
2) When security issues cause usability problems, we will make it clear to administrators how to lower the security, and what the risks are in doing so. (This should be in our usability guidelines).
3) Individual package writers should inform the public (via the forums) if they are aware of security holes in their software, so that concerned individuals can either fix it themselves, or not use that package.
Of course, if we had the manpower and the inclination (we don't), we could put stuff in the APM that reflected whether packages had been audited for security and against our usability standards. I don't see any volunteers for this, I believe?