java 如何在 Tomcat 6 中合理配置安全策略
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2645298/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to sanely configure security policy in Tomcat 6
提问by cemerick
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.
我使用的是为 Ubuntu Karmic 打包的 Tomcat 6.0.24。Ubuntu Tomcat 包的默认安全策略非常严格，但看起来很简单。在 中/var/lib/tomcat6/conf/policy.d，有多种建立默认策略的文件。
Worth noting at the start:
开头值得注意：
- I've not changed the stock tomcat install at all -- no new jars into its common lib directory(ies), no
server.xmlchanges, etc. Putting the .war file in thewebappsdirectory 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
- 我根本没有更改库存的 tomcat 安装——没有新的 jars 到它的公共 lib 目录中，没有
server.xml更改等。将 .war 文件放在webapps目录中是唯一的部署操作。 - 我正在部署的 Web 应用程序失败，在此默认策略下出现数千次访问拒绝（由于
-Djava.security.debug="access,stack,failure"系统属性而向日志报告）。 - 完全关闭安全管理器不会导致任何错误，并且正确的应用程序功能
What I'd like to do is add an application-specific security policy file to the policy.ddirectory, 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):
我想做的是将特定于应用程序的安全策略文件添加到policy.d目录中，这似乎是推荐的做法。我将此添加到policy.d/100myapp.policy（作为起点 - 我希望最终将授予的权限缩减为仅应用程序实际需要的权限）：
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 codeBasedeclaration. I think that's likely my fundamental problem.
请注意试图找到正确codeBase声明的颠簸。我认为这可能是我的根本问题。
Anyway, the above (really only the first two grants appear to have any effect) almostworks: 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:
我非常确信触发拒绝的实际文件是无关紧要的——它只是我们检查可选配置参数的一些属性文件。有趣的是：
- it doesn't exist in this context
- 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).
- 它在此上下文中不存在
- 该文件不存在的事实最终会引发安全异常，而不是
java.io.File.exists()简单地返回 false（尽管我认为这只是读取权限的语义问题）。
Another workaround (besides just disabling the security manager in tomcat) is to add an open-ended permission to my policy file:
另一个解决方法（除了在 tomcat 中禁用安全管理器）是向我的策略文件添加一个开放式权限：
grant {
permission java.security.AllPermission;
};
I presume this is functionally equivalent to turning off the security manager.
我认为这在功能上等同于关闭安全管理器。
I suppose I must be getting the codeBasedeclaration in my grants subtly wrong, but I'm not seeing it at the moment.
我想我一定是codeBase在我的赠款中得到了微妙的声明，但我目前没有看到它。
回答by Brian
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.
您使用的是 Ubuntu 的包管理版本吗？我们最近做了一个关于安全问题的噩梦，但发现通过单独下载 Tomcat 并使用它，安全问题消失了。
Corroboration:
佐证：
http://www.howtogeek.com/howto/linux/installing-tomcat-6-on-ubuntu/
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.
如果您正在运行 Ubuntu 并希望使用 Tomcat servlet 容器，则不应使用存储库中的版本，因为它无法正常工作。相反，您需要使用我在此处概述的手动安装过程。
回答by anger
Tomcat runs with its own tomcat user. The war files need to be visible to that user - probably worth checking that first?
Tomcat 以自己的 tomcat 用户运行。War文件需要对该用户可见 - 可能值得先检查一下？
回答by StudioEvoque
Are you directly deploying to the ROOT directory ?
你是直接部署到ROOT目录吗？
Usually when you put a war in the webapps folder, say 100myapp.war, it unpacks to a folder named 100myappitself. Shouldn't the grants then be done on this new folder rather than the ROOT folder ?
通常，当您在 webapps 文件夹中放置一个 war 时，例如100myapp.war，它会解压到一个名为100myapp自身的文件夹中。不应该在这个新文件夹而不是 ROOT 文件夹上进行授权吗？
回答by Alan Donnelly
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).
如果这不起作用，那么可能是您现有授权范围之外的某些代码正在访问这些属性文件（例如 servlet 或其他库代码）。
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:
作为一种解决方法，并确认是否是这种情况，您可以对导致问题的 .properties 进行直接授权：
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.
事实上，后者可能是这种情况，因为堆栈跟踪显示了 Tomcat 上下文加载器中的代码。如果对 .properties 的直接授权有效，您可能希望将授权锁定到 org.apache.naming.resources.FileDirContext。
Do you get any stack traces specific to your own code?
您是否获得任何特定于您自己的代码的堆栈跟踪？
