为什么不允许未签名的小程序创建自定义类加载器？答案

【问题标题】：Why aren't unsigned applets allowed to create custom ClassLoaders?为什么不允许未签名的小程序创建自定义类加载器？
【发布时间】：2011-02-05 18:50:14
【问题描述】：

Java 小程序不允许您编写自定义类加载器，除非您对小程序进行签名。为什么会这样？自定义 ClassLoader 只是一个查找类的工具。除了调用私有的“defineClass”方法之外，您实际上无法加载该类，该方法是“受信任的”代码，因为它是由 VM 编写和控制的，而不是由您的 applet 编写和控制的。与动态加载类的能力相比，您获得的权限并不多……这根本算不了什么。

我想作为一个附带问题：有没有其他方法可以动态地从

byte[] => Class

未签名的小程序允许哪些操作？

【问题讨论】：

标签： java security applet classloader unsigned

【解决方案1】：

defineClass 有一个 ProtectionDomain 参数，您可以将其与包含 AllPermission 的 PermissionCollection 一起传递，这将允许您对主机执行任何基本操作。

【讨论】：

那么，实际上，当 ProtectionDomain 提供的权限比加载代码的权限多时，如果此方法抛出异常还不够吗？或者只是将权限限制为当前权限和给定权限的交集（因此小程序可以加载权限低于自身权限的代码）？
这将是向后不兼容的。可以解决问题（java.lang.UntrustedClassLoader 子类、opt-in 注册方式等），但是目前还没有这样的机制。
为什么不兼容？如果我们进行了这个更改（在 defineClass 而不是构造函数中进行安全检查），会破坏什么？
JVM 使用调用堆栈上的任意（可能是非特权）代码调用 loadClass，因此每个自定义类加载器都必须使用 doPrivileged 来确保它授予适当的特权（这样做会绕过 checkPackageAccess） .即使构造函数中的 AccessControlContext 被保存，毫无疑问存在非 applet 非特权类加载器子类，它们使用带有 AllPermission 的 defineClass 来增加它们的权限，并且该机制将被破坏。
这确实只是 JVM 缺少的一个特性。即使只是一个“defineClassUnprivledged”方法也可以，但他们还没有实现它。有一个关于它的错误报告已经存在了 15 年。

【解决方案2】：

注意，您可以使用java.net.URLClassLoader.newInstance 创建ClassLoader。正如 bkail 所指出的，自定义 ClassLoader 可以创建具有任意权限的类，以及绕过其他安全约束。至于为什么没有比java.net.URLClassLoader.newInstance 更笼统的东西，嗯，就是没有。

【讨论】：