CODEWITHSUNDEEP
javatomcatubuntutomcat6securitymanager
cemerick
cemerick

Reputation: 5916

How to sanely configure security policy in Tomcat 6

I'm using Tomcat 6.0.24, as packaged for Ubuntu Karmic. The default security policy of Ubuntu's Tomcat package is pretty stringent, but appears straightforward. In /var/lib/tomcat6/conf/policy.d, there are a variety of files that establish default policy.

Worth noting at the start:

What I'd like to do is add an application-specific security policy file to the policy.d directory, which seems to be the recommended practice. I added this to policy.d/100myapp.policy (as a starting point -- I would like to eventually trim back the granted permissions to only what the app actually needs):

grant codeBase "file:${catalina.base}/webapps/ROOT.war" {
  permission java.security.AllPermission;
};

grant codeBase "file:${catalina.base}/webapps/ROOT/-" {
  permission java.security.AllPermission;
};

grant codeBase "file:${catalina.base}/webapps/ROOT/WEB-INF/-" {
  permission java.security.AllPermission;
};

grant codeBase "file:${catalina.base}/webapps/ROOT/WEB-INF/lib/-" {
  permission java.security.AllPermission;
};

grant codeBase "file:${catalina.base}/webapps/ROOT/WEB-INF/classes/-" {
  permission java.security.AllPermission;
};

Note the thrashing around attempting to find the right codeBase declaration. I think that's likely my fundamental problem.

Anyway, the above (really only the first two grants appear to have any effect) almost works: the thousands of access denials are gone, and I'm left with just one. Relevant stack trace:

java.security.AccessControlException: access denied (java.io.FilePermission /var/lib/tomcat6/webapps/ROOT/WEB-INF/classes/com/foo/some-file-here.txt read)
  java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
  java.security.AccessController.checkPermission(AccessController.java:546)
  java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
  java.lang.SecurityManager.checkRead(SecurityManager.java:871)
  java.io.File.exists(File.java:731)
  org.apache.naming.resources.FileDirContext.file(FileDirContext.java:785)
  org.apache.naming.resources.FileDirContext.lookup(FileDirContext.java:206)
  org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:299)
  org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:1937)
  org.apache.catalina.loader.WebappClassLoader.findResource(WebappClassLoader.java:973)
  org.apache.catalina.loader.WebappClassLoader.getResource(WebappClassLoader.java:1108)
  java.lang.ClassLoader.getResource(ClassLoader.java:973)

I'm pretty convinced that the actual file that's triggering the denial is irrelevant -- it's just some properties file that we check for optional configuration parameters. What's interesting is that:

  1. it doesn't exist in this context
  2. the fact that the file doesn't exist ends up throwing a security exception, rather than java.io.File.exists() simply returning false (although I suppose that's just a matter of the semantics of the read permission).

Another workaround (besides just disabling the security manager in tomcat) is to add an open-ended permission to my policy file:

grant {
  permission java.security.AllPermission;
};

I presume this is functionally equivalent to turning off the security manager.

I suppose I must be getting the codeBase declaration in my grants subtly wrong, but I'm not seeing it at the moment.

Upvotes: 17

Views: 13455

Answers (4)

Brian
Brian

Reputation: 6450

Are you using Ubuntu's package-managed version? We had a nightmare recently with security stuff with it, but found that by downloading Tomcat separately and using that, the security issues went away.

Corroboration:

http://www.howtogeek.com/howto/linux/installing-tomcat-6-on-ubuntu/

If you are running Ubuntu and want to use the Tomcat servlet container, you should not use the version from the repositories as it just doesn’t work correctly. Instead you’ll need to use the manual installation process that I’m outlining here.

Upvotes: 2

Alan Donnelly
Alan Donnelly

Reputation: 1525

It's possible that you have to grant file access permissions separately. Try changing the grant for your app to:

grant codeBase "file:${catalina.base}/webapps/ROOT.war" {
  permission java.security.AllPermission;
  permission java.io.FilePermission "file:${catalina.base}/webapps/ROOT/-", "read, write";
}

If that doesn't work, then it could be that some code outside of what your existing grants cover is accessing those property files (e.g. servlet or other library code).

As a workaround, and to confirm if this is the case, you could do a straight grant on the .properties that are causing you the problem:

grant {
  permission java.io.FilePermission "file:${catalina.base}/webapps/ROOT/WEB-INF/classes/com/foo/some-file-here.txt", "read, write";
}

It seems in fact that the latter could be the case since the stack trace shows code in Tomcat's context loader. If the straight grant on the .properties works, you might want to lock the grant down to org.apache.naming.resources.FileDirContext.

Do you get any stack traces specific to your own code?

Upvotes: 0

StudioEvoque
StudioEvoque

Reputation: 912

Are you directly deploying to the ROOT directory ?

Usually when you put a war in the webapps folder, say 100myapp.war, it unpacks to a folder named 100myapp itself. Shouldn't the grants then be done on this new folder rather than the ROOT folder ?

Upvotes: 0

anger
anger

Reputation: 1018

Tomcat runs with its own tomcat user. The war files need to be visible to that user - probably worth checking that first?

Upvotes: 0

Related Questions