Java 如何在Tomcat 6中合理配置安全策略

我正在使用Tomcat6.0.24，它是为Ubuntu Karmic打包的。Ubuntu的Tomcat包的默认安全策略非常严格，但看起来很简单。在

/var/lib/tomcat6/conf/policy.d

中，有各种文件建立默认策略

首先值得注意的是：

• 我根本没有改变tomcat的安装——没有新的JAR进入它的公共lib目录，没有

  server.xml

  changes等等。将.war文件放入

  webapps

  目录是唯一的部署操作
• 我正在部署的web应用程序在此默认策略下失败，并出现数千次访问拒绝（由于系统属性

  -Djava.security.debug=“access，stack，failure”

  而在日志中报告）
• 完全关闭安全管理器不会导致任何错误和正确的应用程序功能

我想做的是将特定于应用程序的安全策略文件添加到

policy.d

目录，这似乎是推荐的做法。我将此添加到

policy.d/100myapp.policy

（作为起点——我希望最终将授予的权限缩减到应用程序实际需要的权限）：

请注意，在试图找到正确的

codeBase

声明时，会发生反复。我想这可能是我的根本问题

无论如何，上述（实际上只有前两项补助金似乎有任何效果）几乎奏效：成千上万的访问拒绝消失了，而我只剩下一项。相关堆栈跟踪：

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)

我非常确信触发拒绝的实际文件是不相关的——它只是我们检查可选配置参数的一些属性文件。有趣的是：

在这种情况下，它并不存在

文件不存在的事实最终引发了一个安全异常，而不是

java.io.file.exists（）

简单地返回false（尽管我认为这只是读取权限的语义问题）

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

grant {
  permission java.security.AllPermission;
};

我认为这在功能上相当于关闭安全管理器

---

我想我的授权中的

codeBase

声明一定是有点错误，但我现在没有看到它。

Tomcat使用自己的Tomcat用户运行。war文件需要对该用户可见-可能值得先检查一下吗？

是否直接部署到根目录

---

通常，当您将war放入webapps文件夹时，例如

100myapp.war

，它会解压到名为

100myapp

的文件夹中。难道不应该在这个新文件夹而不是根文件夹上进行授权吗

您可能需要单独授予文件访问权限。尝试将应用程序的授权更改为：

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

如果这不起作用，那么可能是现有授权范围之外的一些代码正在访问这些属性文件（例如servlet或其他库代码）

作为一种解决方法，为了确认是否存在这种情况，您可以直接授予导致问题的.properties：

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

事实上，后者可能是这样，因为堆栈跟踪显示Tomcat的上下文加载程序中的代码。如果.properties上的直接授权有效，您可能希望将授权锁定到org.apache.naming.resources.FileDirContext

---

您是否有特定于自己代码的堆栈跟踪？

您是否使用Ubuntu的包管理版本？我们最近做了一个关于安全性的噩梦，但是发现通过单独下载Tomcat并使用它，安全性问题消失了

佐证：

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

---

是的，所有有问题的文件（包括.war文件和分解的应用程序目录）都属于tomcat6:tomcat6，tomcat服务器运行的用户是同一个用户。一般来说，我们将应用程序部署为

ROOT.war

，因此它将解包到

ROOT

目录。为了防止这是问题的根源，我还尝试部署到另一个路径（

foo.war

），根据需要更新授权（参考

foo.war

和解包的

foo

目录。抱歉，没有骰子：添加文件权限w/“读、写”我所拥有的所有授权的选项都没有改变任何东西。然而，我确实认为这一理论中有一些东西：tomcat加载的默认策略文件（位于

/var/lib/tomcat6/work/catalina.policy

），已为我使用的代码库指定了授权，但其中包括AllPermission和FilePermission。尽管快速测试表明前者意味着后者。不幸的是，特定文件上的总体授权也没有改变行为。而且，没有，我从代码库中看不到堆栈跟踪。我们没有问题除了这个安全管理器问题之外，还有tomcat的问题——它是以什么方式“不能正常工作”的对你来说？FWIW，链接的文章已经3年了，评论是指ubuntu 7.x。不过，我会给你一个手动安装的机会，看看会发生什么。这都是与安全管理器有关的，我们遇到的问题。也就是说是我团队的一位同事与之发生了冲突，他现在离开了公司，所以我不能给你任何细节。参见但是你的问题是，除了ubuntu上打包的tomcat之外，我从来没有听说过这样的问题，这对我来说是一个巨大的红色警报，并且使用独立安装是无缝的。出于好奇，你是如何开始手动安装的？

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