Java ClassLoader安全模型

Question

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

根据Sandboxing上的JVM规范,我相信标准的JVM实现应该至少保留一个其他的ClassLoader,独立于primordial ClassLoader.这用于加载应用程序类文件(例如,从提供的类路径).

例如,如果ClassLoader从不在其命名空间中的类请求该类java/lang/String,则它将请求转发到原始语句ClassLoader,该原语尝试从Java API加载该类,如果它不在那里则抛出一个NoClassDefFoundError.

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

这使得类的加载更加安全,因为这意味着恶意类不能伪装成Java API的成员(比方说java/lang/Virus),因为这是一个受保护的命名空间,并且不能在当前使用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.由于非技术原因,前缀受到特别保护.

通常,类加载器将在定义新类之前委托给其父类,从而防止替换祖先加载器中的任何类.Java EE建议(即使Java SE禁止)有一些类加载器更喜欢自己的类,通常使用更新的API或不同的实现.这允许类的阴影,但只能通过该加载器(及其子项)看到.所有其他类继续链接到原始类.