将 Tomcat 与 Java SecurityManager 结合使用？
我正在编写一个应该在 Ubuntu 上的 Tomcat 上运行的 Web 应用程序。 在 Ubuntu 上，Tomcat 默认配置为与 Java SecurityManager 一起运行。 除了我自己的 Web 应用程序之外，只会有一些与我自己的相关的知名第三方 Web 应用程序，例如 BIRT 报告引擎。
如果其中一个 Web 应用程序出现故障或受到损害，它可能会在没有损害的情况下关闭所有其他应用程序，因为它们都是一体的。 我不会发生的是，受感染的 Web 应用程序会损害系统本身，例如调用 rm -r /
我是否需要使用 java 安全管理器来实现此目的？ 或者只需要保护一个网络应用程序免受另一个网络应用程序的侵害？ 我真的很想阻止为我打算使用的所有第 3 方 Web 应用程序创建 .policy 文件。
I'm writing a web application that is supposed to run on Tomcat on Ubuntu. On Ubuntu, Tomcat is per default configured to run with the Java SecurityManager. Besides my own web application, there will only be some well known third party web applications related to my own, like the BIRT report engine.
If one of the web applications fails or gets compromised, it may take down all the others without harm, because they all belong together. What I don't wont to happen is that a compromised web app compromises the system itself, like calling rm -r /
Do I need to use the java security manager to achieve this? Or is it only necessary to protect one web app from the other? I'd really like to prevent the effort to create .policy files for all the 3rd party web applications I intend to use.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
理论上是的。 但我听说人们在尝试使用安全管理器“锁定”服务器端代码时遇到了很多问题。 应用程序的设计通常没有考虑到这一点，并且您花费大量时间调试 SecurityExceptions，直到获得正确的所有权限设置。
编辑：
我建议运行两个 Tomcat 实例更简单，以避免一个应用程序执行某些操作会导致单个 Tomcat 中的所有内容崩溃的问题。 （例如，填充堆、泄漏文件描述符或...调用 System.exit()。）
如果您仍然担心应用程序“突破”Java 并执行相当于“rm /*”的操作，那么您可以在单独的“chroot监狱”或虚拟主机中运行每个Tomcat实例。 或者，您可以简单地从受限用户帐户运行 Tomcat，并确保该帐户无法访问/更新不应访问/更新的文件。
In theory yes. But I've heard that people run into stacks of problems when they try to "lock down" server side code using the security manager. Applications are frequently not designed with this in mind, and you spend a lot of time debugging SecurityExceptions until you get all of the permissions settings right.
EDIT:
I suggest that is simpler to run two Tomcat instances to avoid the problem of one application doing something that will bring down everything in a single Tomcat. (For example, fill up the heap, leak file descriptors or ... call System.exit().)
If you still are worried about an application "breaking out" of Java and doing the equivalent of "rm /*", then you could run each Tomcat instance in a separate "chroot jail" or a virtual host. Or you could simply run Tomcat from a restricted user account and make sure that the account cannot access / update files that it should not.
避免“
rm -r /”不需要安全管理器。 如果运行 Tomcat 进程的用户具有有限的访问权限（即没有对/或任何其他重要区域的写入权限），则这就足够了。Avoiding a "
rm -r /" doesn't require a security manager. It is sufficient if the user that runs the Tomcat process has limited access (i.e. doesn't have write access to/or any other important area).SecurityManager 只是您可以应用于 Tomcat 的另一层安全性，并且根据您的应用程序，正确使用它可能非常困难且耗时。 正如您已经指出的，为第三方应用程序和库实现这一点可能会更加困难。
在我看来，进行任何细节配置都是您最不应该考虑的事情。
这里已经说了很多内容，但如果我是你，我会按顺序执行以下步骤：
有关 jsvc 的更多信息，请参阅 http://tomcat.apache.org/tomcat- 6.0-doc/setup.html
您可以做的其他事情包括在计算机上运行 Snort 等 IDS 来检测某些入侵尝试，运行 swatch 等文件观察器来检测意外的文件修改（尤其是配置文件）以及运行各种日志分析器来尝试检测任何其他入侵尝试。
任何安全努力总是需要做出权衡。 您永远无法完全保护您的应用程序，并且总有一天，进一步的努力是不值得的。 对于大多数人来说，完整的安全管理器配置属于这一类。
“我需要使用 java 安全管理器来实现此目的[损害系统本身]吗？”
不。有更简单的方法（低权限帐户、chroot、安全配置等）
SecurityManager is just another layer of security you can apply to Tomcat and, depending your application, can be very difficult and time consuming to get right. As you've already noted, getting this right for third party applications and libraries can be even more difficult.
In my opinion, configuring this in any detail is the last thing you should be considering.
Much of this has been said already here, but if I were you, I'd follow these steps, in order:
For more on jsvc, see http://tomcat.apache.org/tomcat-6.0-doc/setup.html
Other things you can do include running an IDS like Snort on the machine to detect some intrusion attempts, running a file watcher like swatch to detect unexpected file modifications (especially to configuration files) and running various log analysers to attempt detect any other attempts at intrusion.
There's always a tradeoff to be made with any security effort. You can never totally secure your application and there always comes a point when further effort just isn't worth it. A full blown security manager configuration, for most people, falls into this category.
"Do I need to use the java security manager to achieve this [compromising the system itself]?"
No. There are easier ways (low privilege account, chroot, secure config etc.)