如何安全地实现Java插件安全性？

我正在设计一个在Java应用程序中加载、处理和支持插件的系统。我觉得在部署之前，有一个特性是绝对重要的，那就是能够建立一个安全的环境，在这个环境中，插件被限制在允许的范围内

我无法理解如何以编程方式使用策略文件，而不在启动时运行-Djava.security.manager参数。现在就到此为止

我的下一个想法是在我自己的SecurityManager子类中覆盖我在SecurityManager中关心的所有方法，并限制谁可以执行它们

然后问题出现了，查明谁在请求此权限的唯一方法是通过线程ID检查。因此，我设计了一个系统，所有插件线程都驻留在其中，并且只能驻留在PluginThreads线程组中

那起作用了。。。直到一切开始爆炸。问题是被阻止的部分内容是Sun代码执行的内部操作

因此，即使是最基本的操作，如打开窗口，也会失败，因为我的安全经理拒绝访问Sun的代码。使用我的线程检查方法并没有解决这个问题，因为Sun的代码是在PluginThreads组中执行的

所以我需要知道的是：

1） 是否有可能通过使用当前线程来确定调用的上下文

2） 有没有更好的方法来做这件事，我不知道

3） 如果该方法涉及策略文件，如何将它们加载到代码中

---

4） 有没有其他方法可以防止Sun的内部Java代码被阻止？

您需要使用

Java.security.AccessController

/

AccessControlContext

和

SecurityManager

。API支持类型为

object

的上下文对象，但实际上需要使用

AccessControlContext

。要为用户代码提供正确的权限，请通过

SecureClassLoader

的子类提供相关的

ProtectionDomain

（

URLClassLoader.newInstance

是您必须正确操作的合理示例）

对于GUI应用程序（例如，这包括使用

java.beans

特定部分的任何内容），您还需要处理

AppContext

（在java库的“Sun”实现中）。这不是一个公共API

---

线程和线程组不是管理安全性的好方法。不幸的是，这是

AppContext

隔离工作的一部分。

SecurityManager

是一个可怕的烂摊子。而不是反复地授予更多可能滥用的权限，直到它似乎工作，你应该考虑要求插件写入java的子集，使你能够充分地思考他们能做什么。 提供可分解的安全性。发件人：

我们介绍了Joe-E，一种旨在支持安全软件系统开发的语言。Joe-E是Java的一个子集，它使构建和实现具有强大安全属性的程序变得更加容易，这些属性可以在安全审查期间进行检查。它使程序员能够将最小特权原则应用于他们的程序；实施无法绕过的特定于应用程序的参考监控器；介绍和使用特定领域的安全抽象安全地执行不受信任的代码并与之交互；并建立安全、可扩展的系统。Joe-E演示了如何在保持主流面向对象语言的特性和感觉的同时，实现对象功能语言的强大安全特性

---

是的，我注意到线程检查是一种处理安全性的糟糕方法。AccessControlContext是否不干扰Sun代码？@ghostsoldier23您的意思是“Java库代码如何不导致所有acc检查失败？”？它拥有所有权限。通常，库代码至少需要与使用它的应用程序相同的权限。通常，这意味着库拥有所有权限，或者它与具有应用权限的应用捆绑在一起。你是说AppContext是com.sun.*库的一部分吗？“禁止”、“你不得通过”图书馆；d这是否涉及创建策略文件？@ghostsoldier23比

com.sun.*

，

AppContext

在

sun.*

中。不是有文档记录的公共API，在更新和潜在的“最终”更新版本之间可能会发生更改，恕不另行通知。虽然通过系统类加载器加载的类通常没有特权（只有在安装

SecurityManager

后才强制执行），但您并不绝对需要策略文件。我相信Joe-E目前只适用于Java源代码，而不是Java字节码。因此，您必须将插件作为源代码分发。我不完全确定Joe-E的状态。然而，这是非常粗略的Java2应该如何完成的。@TomHawtin tackline，我相信你是正确的。说“我们对Java源代码而不是Java类文件执行检查，因为Java运行时只对字节码进行有限的验证检查，允许字节码执行Java程序无法执行的许多操作。”这使他们能够访问诸如内部类特权之类的语言虚构，并允许他们忽略受保护区域周围的主要字节码重构，并允许他们跳过关于

javac

不太可能产生的字节码的推理。