The more who review/audit tomcat for security, the better. :-) Comments intermixed below.
Jean-Francois Arcand wrote: > Hi, > > I'm looking to do a Security Audit on the current Tomcat 5.0 codebase. I > would like to collect as more as information as where you think I should > look at (code, security hole, etc.). I'm planning to do the audit using > the default SecurityManager. Rigth now, I have started looking at: > > - doPrivilege blocks. Are they small enough? Can they be reduced? I don't think there are more than a dozen doPrivileged() blocks in all of catalina and jasper. They are relatively few and restricted to a few specific methods in catalina which may get executed by some action a servlet or jsp performs. For example, when a jsp page does a forward. > - JSP generated code. Are they secure? Can a malicious app uses the code > to access o.a.catalina code? Class restrictions are implemented in two ways. First, the catalina core API's are in server/lib so that they are not one of the parent class loaders visible to a web app. Second, the WebappClassLoader implements checkPackageAccess() and checkPackageDefinition(). These are only implemented if Tomcat was started with the SecurityManager. One change we considered with Tomcat 4 was whether it should require using the Java SecurityManager. You may want to open up that debate again with Tomcat 5. > - Is catalina.policy restricted enough? Not for my needs, my security policies are much more restrictive. But restrictive enough for some users. Perhaps there should be a second more restrictive example catalina.policy. > - Is our Classloader secure? > > Any direction/ideas/recommendations will be appreciated. > I don't have time right now to particpate in the security audit, but I will make sure I review any findings. One item that has been on my todo list for a while is a document on how to write SecurityManager and web application friendly code. I find numerous packages, frameworks, etc. which perform things in ways which are not friendly to the SecurityManager or a web application. I have been known to file bug reports with other jakarta projects when I run across these issues. :-) Regards, Glenn -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
