如何在Tomcat 6中合理配置安全策略 [英] How to sanely configure security policy in Tomcat 6

问题描述

我正在使用Tomcat 6.0.24，为Ubuntu Karmic打包。 Ubuntu的Tomcat软件包的默认安全策略非常严格，但看起来很简单。在 /var/lib/tomcat6/conf/policy.d 中，有多种文件可以建立默认策略。

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.

一开始值得注意：

• 我根本没有改变库存tomcat安装 - 没有新的罐子进入它的共同点lib目录，没有 server.xml 更改等。将.war文件放在 webapps 目录中唯一的部署操作。


• 我正在部署的Web应用程序失败，在此默认策略下有数千个访问拒绝（由于 -Djava而报告给日志） .security.debug =访问，堆栈，失败系统属性）。


• 完全关闭安全管理器不会导致任何错误，并且具有适当的应用功能

• I've not changed the stock tomcat install at all -- no new jars into its common lib directory(ies), no server.xml changes, etc. Putting the .war file in the webapps directory is the only deployment action.
• the web application I'm deploying fails with thousands of access denials under this default policy (as reported to the log thanks to the -Djava.security.debug="access,stack,failure" system property).
• turning off the security manager entirely results in no errors whatsoever, and proper app functionality

我想要做的是在 policy.d中添加特定于应用程序的安全策略文件。 目录，这似乎是推荐的做法。我将此添加到 policy.d / 100myapp.policy （作为起点 - 我希望最终将授予的权限减少到应用程序实际需要的权限）：

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;
};

请注意试图找到合适的 codeBase 声明。我认为这可能是我的根本问题。

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. 在此背景下不存在


2. 事实是文件不存在最终抛出一个安全异常，而不是 java.io.File.exists（）只返回false（虽然我认为这仅仅是语义问题读取权限）。

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).

另一种解决方法（除了禁用tomcat中的安全管理器）是添加一个开放式权限我的政策文件：

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.

我想我必须在我的授权中获得 codeBase 声明，但我现在还没有看到它。

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

推荐答案

您使用的是Ubuntu的软件包托管版本吗？我们最近遇到了一个关于安全问题的噩梦，但发现通过单独下载Tomcat并使用它，安全问题就消失了。

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.

确证：

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

如果你是运行Ubuntu并希望使用Tomcat servlet容器，您不应该使用存储库中的版本，因为它无法正常工作。相反，您需要使用我在此概述的手动安装过程。

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.

这篇关于如何在Tomcat 6中合理配置安全策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！