说明: 安全策略只对安装安全管理器之后的类生效,之前的类不再此管理范围之内,利用这一点可以预先设置我们需要的操作,而对某个点之后的所有非法操作进行权限设置.
说明,本文部分内容转自:http://galaxystar.javaeye.com/blog/225615
参考书籍:《Inside the Java Virtual Machine,Second Edition》
组成Java沙箱的基本组件如下:
·类加载体系结构
·class文件检验器
·内置于Java虚拟机(及语言)的安全特性
·安全管理器及Java API
Java安全模型的前三个部分——类加载体系结构、class文件检验器、Java虚拟机(及语言)的安全特性一 起达到一个共同的目的:保持Java虚拟机的实例和它正在运行的应用程序的内部完整性,使得它们不被下载的恶意代码或有漏洞的代码侵犯。相反,这个安全模 型的第四个组成部分是安全管理器,它主要用于保护虚拟机的外部资源不被虚拟机内运行的恶意或有漏洞的代码侵犯。这个安全管理器是一个单独的对象,在运行的 Java虚拟机中,它在对于外部资源的访问控制起中枢作用。
类加载体系结构
类加载器要加载一个类,它首先检查此类是否已被加载,然后再委托双亲加载器加载此类,它的双亲加载器再委托它的双亲,这样一直委托到启 动加载器,启动加载器在从核心API查找此类,如果有就返回此类,否则就他的子加载器就查找此类,如果都没有就抛出ClassNotFound的异常。如 下图所示:
这种委托双亲的模式好处是:启动类加载器可以抢在标准扩展类装载器之前去装载类,而标准扩展类装载器可以抢在类路径加载器之前去装载那个类,类路径 装载器又可以抢在自定义类加载器之前去加载它。所以Java虚拟机先从最可信的Java核心API查找类型,这是为了防止不可靠的类扮演被信任的类,试想 一下,网络上有个名叫java.lang.Integer的类,它是某个黑客为了想混进java.lang包所起的名字,实际上里面含有恶意代码,但是这 种伎俩在双亲模式加载体系结构下是行不通的,因为网络类加载器在加载它的时候,它首先调用双亲类加载器,这样一直向上委托,直到启动类加载器,而启动类加 载器在核心Java API里发现了这个名字的类,所以它就直接加载Java核心API的java.lang.Integer类,然后将这个类返回,所以自始自终网络上的 java.lang.Integer的类是不会被加载的。
但是如果这个移动代码不是去试图替换一个被信任的类(就是前面说的那种情况),而是想在一个被信任的包中插入一个全新的类型,情况会怎样呢?比如一 个名为java.lang.Virus的类,经过双亲委托模式,最终类装载器试图从网络上下载这个类,因为网络类装载器的双亲们都没有这个类(当然没有 了,因为是病毒嘛)。假设成功下载了这个类,那你肯定会想,Virus和lang下的其他类痛在java.lang包下,暗示这个类是Java API的一部分,那么是不是也拥有修改Java.lang包中数据的权限呢?答案当然不是,因为要取得访问和修改java.lang包中的权 限,java.lang.Virus和java.lang下其他类必须是属于同一个运行时包的,什么是运行时包?运行时包是指由同一个类装载器装载的、属 于同一个包的、多个类型的集合。考虑一下,java.lang.Virus和java.lang其他类是同一个类装载器装载的吗?不是 的!java.lang.Virus是由网络类装载器装载的!
class文件校验器,通过四趟扫描,保证了class文件正确
第四趟是,符号引用验证。一个类文件,它会包含它引用的其他类的全名和描述符,并跟他们建立符号引用(一种虚拟的,非物理连接的方式)。当程序第一 次执行到需要符号引用的位置时,jvm会检查这个符号链接的正确性,然后建立真正的物理引用(直接引用)。
内置于Java虚拟机(及语言)的安全特性
这些都是基础的java语言特性,他们降低了java程序出现内存混乱,崩溃的几率。
·结构化内存访问(不使用指针,一定程度上让黑客无法篡改内存数据)
·自动垃圾收集
·数组边界检查
·空引用检查
·数据类型安全
安全管理器及Java API
你可以将这个实例,扔给 SecurityManager,检查是否可读text.txt这个文件