kjkoster
18-08-2008, 08:48
Dear All,
We discussed re-packaged Tomcat installations before (http://java-monitor.com/forum/showthread.php?t=4). Well, I found another issue with one such packaged Tomcat. It seems that the Debian (and Ubuntu) package for Tomcat ships with some really tight settings on the Java security manager (http://tomcat.apache.org/tomcat-5.5-doc/security-manager-howto.html). So tight, in fact, that logging through Tomcat's own JULI system is not enabled by default. On top of that, if your web applications need write permissions, you also have to explicitly allow that.
I'm torn. On the one hand I like the additional security that the security manager provides. On the other hand I am not sure that the non-standard security manager configuration is a good thing. It leads to a lot of frustration with Tomcat when it is really a packaging issue. I does reinforce my idea that Debian admins should start with the officiela binaries from http://tomcat.apache.org/ and only use the Debian package once they are comfortable with Tomcat.
Here is a nice discussion about how to solve security manager issues (http://aleph-null.tv/article/20080416-1439-301.xml/OpenCms-7.04-with-Tomcat-on-Ubuntu-Feisty-(7.10)). The discussion is for OpenCms, but the advise extends well to your own web applications. Oh, and don't be too quick to dole out java.security.AllPermission (http://java.sun.com/javase/6/docs/api/java/security/AllPermission.html) everywhere. It defeats the point of having a security manager in the first place.
In short, the solution is to carefully read the message that comes with the java.security.AccessControlException (http://java.sun.com/javase/6/docs/api/java/security/AccessControlException.html). Based on that message you can quickly fix the permissions in your security policy. It's largely cut'n-paste even.
Do you use custom security policies in production? If so, what type of permissions do you grant and what do you block?
Kees Jan
We discussed re-packaged Tomcat installations before (http://java-monitor.com/forum/showthread.php?t=4). Well, I found another issue with one such packaged Tomcat. It seems that the Debian (and Ubuntu) package for Tomcat ships with some really tight settings on the Java security manager (http://tomcat.apache.org/tomcat-5.5-doc/security-manager-howto.html). So tight, in fact, that logging through Tomcat's own JULI system is not enabled by default. On top of that, if your web applications need write permissions, you also have to explicitly allow that.
I'm torn. On the one hand I like the additional security that the security manager provides. On the other hand I am not sure that the non-standard security manager configuration is a good thing. It leads to a lot of frustration with Tomcat when it is really a packaging issue. I does reinforce my idea that Debian admins should start with the officiela binaries from http://tomcat.apache.org/ and only use the Debian package once they are comfortable with Tomcat.
Here is a nice discussion about how to solve security manager issues (http://aleph-null.tv/article/20080416-1439-301.xml/OpenCms-7.04-with-Tomcat-on-Ubuntu-Feisty-(7.10)). The discussion is for OpenCms, but the advise extends well to your own web applications. Oh, and don't be too quick to dole out java.security.AllPermission (http://java.sun.com/javase/6/docs/api/java/security/AllPermission.html) everywhere. It defeats the point of having a security manager in the first place.
In short, the solution is to carefully read the message that comes with the java.security.AccessControlException (http://java.sun.com/javase/6/docs/api/java/security/AccessControlException.html). Based on that message you can quickly fix the permissions in your security policy. It's largely cut'n-paste even.
Do you use custom security policies in production? If so, what type of permissions do you grant and what do you block?
Kees Jan