Java ClassLoader安全模型
|
我正在尝试理解在要求JVM加载类时使用的安全模型.
根据Sandboxing上的JVM规范,我认为标准JVM实现应该至少保留一个其他ClassLoader,独立于原始ClassLoader.这用于加载应用程序类文件(例如,从提供的类路径). 如果从不在其命名空间的ClassLoader中请求类,例如java / lang / String,那么它会将请求转发给原始的ClassLoader,它试图从Java API加载该类,如果它不在那里那么它抛出NoClassDefFoundError. 我是否正确地认为原始的ClassLoader只从Java API命名空间加载类,而所有其他类都是通过单独的ClassLoader实现加载的？ 这使得类的加载更加安全,因为这意味着恶意类不能伪装成Java API的成员(比如java / lang / Virus),因为这是受保护的命名空间,不能在当前的ClassLoader中使用？ 但有什么可以防止Java API的类被恶意类替换,还是会在类验证期间检测到？ 解决方法
由于历史原因,用于类加载器的名称有点特殊.引导类加载器加载系统类.默认情况下,系统类加载器从类路径而不是系统类加载类.系统类位于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或不同的实现.这允许类的阴影,但只能通过该加载器(及其子项)看到.所有其他类继续链接到原始类. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |