java - Java 类加载器安全模型

Question

我正在尝试了解要求 JVM 加载类时使用的安全模型。

根据关于沙盒的 JVM 规范，我相信标准的 JVM 实现应该至少维护一个其他 ClassLoader，独立于 primordial ClassLoader。这用于加载应用程序类文件(例如从提供的类路径)。

如果从不在其命名空间中的 ClassLoader 请求该类，例如 java/lang/String，则它将请求转发到原始 ClassLoader，它尝试从 Java API 加载类，如果不存在，则抛出 NoClassDefFoundError。

我是否认为原始的 ClassLoader 仅从 Java API 命名空间加载类，而所有其他类都是通过单独的 ClassLoader 实现加载的？

这使得类的加载更加安全，因为这意味着恶意类无法伪装成 Java API 的成员(比方说 java/lang/Virus)，因为这是一个 protected 命名空间，并且不能在当前的 ClassLoader 中使用？

但是有什么可以防止 Java API 的类被恶意类替换，或者在 class 验证期间会被检测到吗？

Answer 1

由于历史原因，用于类加载器的名称有点特殊。引导类加载器加载系统类。默认情况下，系统类加载器从类路径而不是系统类加载类。系统类位于 jre/lib(主要在 rt.jar 中)、认可的目录以及通过 -Xbootclasspath 添加的任何位置。

在 Sun/Oracle JRE 上，rt.jar 包含带有以 java.、javax.、sun.、com.sun.、org.omg、org.w3c 和 org.xml 开头的包的类。

不受信任的代码(包括配置)不应添加到系统类中。某些包名称前缀可能会受到安全属性的限制。 java 。由于非技术原因，前缀受到特别保护。

通常，类加载器会在定义新类之前委托(delegate)给其父类，以防止替换祖先加载器中的任何类。 Java EE 建议(即使 Java SE 禁止)让一些类加载器更喜欢它们自己的类，通常是为了使用更新的 API 或不同的实现。这允许隐藏类，但仅限于通过该加载程序(及其子项)看到的。所有其他类继续链接到原始类。