Java虚拟机体系结构 - Java安全模型

Java安全模型的目的：

侧重于保护终端用户免受从网络下载的、来自不可靠来源的而已程序以及善意程序中bug的侵犯。为了达到这个目的，Java提供了一个用户可配置的“沙箱”，在沙箱中可以放置不可靠的Java程序。沙箱限制了不可靠的程序的活动范畴，使程序的活动限定在了一个安全的范围内（譬如限制Java程序对硬盘的读写、进行网络连接、创建新的进程和装载新的动态链接库等等）。最初的Java1.0版本的沙箱安全模型对不可靠代码能做什么，不能做什么进行了严格的控制，所以用户可以相对安全的运行不可靠代码，另一方面，由于沙箱的限制太过严格，善意（但不可靠）的代码常常无法进行有效的工作，因此通过对最初沙箱模型的改进，引入了Java1.1版本的基于代码签名和认证的信任模式以及1.2版本的细粒度访问访问控制。

基本沙箱的组成：

• 类装载器
• class文件检验器
• 内置于Java虚拟机（及语言）的安全特性
• 安全管理器及Java API

Java沙箱安全模型最重要的有点之一就是类装载器和安全管理器可以由用户定制。在Java1.0/1.1版本中，访问控制（包括安全策略规范和运行时安全策略的实施)是通过一个安全管理器的对象负责的,用户必须编写自己的定制安全管理器。在版本1.2中，可以利用Java 2平台提供的安全管理器，这个预先制定好的安全管理器，允许用户在一个和程序分离的ASCII策略文件中说明安全策略。在运行时，这个预先制作好的安全管理器获得一个类（称为访问控制器）的帮助，来执行在策略文件中索命的安全策略。在版本1.2中引入的访问控制基础架构提供了灵活易定制的安全管理器的默认实现，这个默认实现可以满足大多数的安全需要（为了向后兼容以及满足一些特殊安全的需求，可以对预先制定好的安全管理器中的默认功能进行改写）。

类装载器：

在Java沙箱中，类装载器是安全的第一道防线，它通过以下三个方面对Java沙箱起作用：

• 放置而已代码区干涉善意代码（通过不同类装载器提供的不同命名空间来实现）
• 守护了被信任的类库的边界
• 通过将代码归入某个类（保护域），该类确定了该代码可以进行的操作

命名空间有助于安全的实现，因为你可以有效地在装入了不同命名空间的类之间设置一个防护罩；在java虚拟机中，在同一个命名空间的类可以直接相互访问，而不同的命名空间中的类甚至不能察觉彼此的存在，除非显示地提供允许他们交互的机制。如图1-1，每个命名空间都被关联到方法区中的一个类型数据，这个类型数据用哪个名字定义了一个类型。

图1-1 类装载器和命名空间

类装载器守护了被信任的类库的边界，通过使用不同的类装载器装载可靠和不可靠的包来实现。虽然通过赋予成员（或包访问）受保护的访问限制，可以在同一个包中的类型间授予彼此访问的特殊权限，但这种特殊的权限只能授给在同一个包中的运行时成员，而且他们必须是由同一个类装载器装载的。类装载器可以请求另一个用户自定义装载器来装载一个类，这个请求时通过对被请求的用户自定义装载器调用loadClass( )来实现的。除此之外，类装载器也可以通过findSystemClass( ) 来请求启动类装载器来装载类库中包含Java API的基本class文件。在版本1.2开始，除启动类装载器以外，每个类装载器都有一个“双亲”类装载器，在某个特定的类装载器试图以常用方式装载类型以前，它会默认地将这个任务“委派”给双亲来装载这个类型。图1-2展示了定义了一个通过从网络下 载class文件的类装载器的Java应用程序。在应用程序启动时，标准扩展类装载器和类路径装载器和启动类装载器一起连入双亲-孩子关系链中（类路径装载器被设计成系统类装载器）。当自定义类装载器发出装载一个需从网络上下载的class文件时，须先委派它的双亲（类路径装载器）来查找并装载这个类，类路径类装载器以及其双亲类装载器向它自己的双亲发出同样的请求，直至启动类装载器。因为启动类装载器不能够装载该类，因此返回到其子类装载器中，同样，标准扩展类装载器和类路径类装载器都不能装载该class文件，最后返回到网络类装载器中，下载并装载该class文件：

图 1-2 双亲-孩子类装载器外派链

class 文件检验器（附：class文件格式）：

class文件检验器要进行四趟独立的扫描来完成它的操作。第一趟扫描是在类被装载时进行的，在这次扫描中，class文件检验器查找这个class文件的内部结构，以保证它可以被安全地编译（确保字节序列遵循Java class文件的固定格式，这样它才能被编译成在方法区中的内部数据结构）；第二趟和第三趟扫描是在连接过程中进行的，这两次扫描用来保证类型数据遵从java编程语言的定义，包括检验它所包含的所有自己码的完整性（在方法区中，第二趟扫描确保每个组成部分（如方法描述符）必须符合特定的上下文无关文法，而不去查看它的字节码；第三趟对字节码进行检查，确保从字节码中能够得到一个确定的操作码以及操作数栈总是包含正确的数值和类型）；第四趟扫描是在进行动态链接的过程中解释符号引用时进行的，这次扫描确认被引用的类、字段以及方法确实存在（在动态链接过程中，确保从被验证的class文件中的符号引用的正确性）。

java虚拟机内置的安全特性：

• 类型安全的引用转换
• 结构化的内存访问（无指针算法）
• 自动垃圾收集（不必显示地释放被分配的内存） 
• 数组边界检查
• 空引用检查

结构化的内存访问机制（Java语言不提供分结构化的内存访问，字节码指令集本身禁止这种非结构化的访问）使得Java程序更加健壮，也使得其运行更为安全；另一方面，Java字节码文件中不提供运行时数据空间的内存分布，因此，通过阅读Java虚拟机规范或者仅凭class文件中的内容不可能知道内存中哪些数据代表某个类后从那个类实例化得到的对象。

安全管理器和Java API：

Java安全模型的前三个部分（类装载器体系结构、class文件检验器以及Java中内置的安全特性）一起达到一个共同目的：保持Java虚拟机的实例和它正在运行的应用程序的内部完整性，使得它们不被下载的恶意或由漏洞的代码侵犯。而安全管理器（一个管理外部资源访问控制的单独对象），它主要用于保护虚拟机的外部资源不被虚拟机内运行的恶意或者有漏洞的代码侵犯。

        当Java程序启动时，它还没有安全管理器，应用程序将一个指向java.lang.SecurityManager（版本1.2中是一个具体的类，它提供一个默认的安全管理器的实现，这个默认的实现被称为 具体安全管理器）或是其子类的实例传给setSecurityManager( )，以此来安装安全管理器（可选的，如果不安装安全管理器，那么它将不会对请求java API 的任何动作限制）。用户可以在命令行使用选项 -Djava.security.manager来指明安装具体安全管理器。具体安全管理器类使用户能够通过编写一个ASCII的策略文件来定义自己的策略；当创建安全管理器时，具体安全管理器对策略文件进行解析，并创建CodeSource（代码来源 - 由代码库的URL和一些签名组成，从这个URL可以装在代码，而签名则为这个代码作担保）和Permission（权限 - 它是java.security.Permission的子类）对象，这些对象被封装在一个单独的Policy对象中，这个Policy对象代表了运行时的策略。类装载器将类型放到保护域（ProctionDomain）中，保护域封装了授予代码来源的所有权限，这些代码来源由装载的类型代表（在版本1.2中，每个被装载在虚拟机中的类型都属于且只属于一个保护域）。当具体安全管理器的check方法被调用时，他们中的大多数都将强求传递给一个称为AccessController的类，这个类定义了一个checkPermission( )的静态方法，这个方法决定一个特定的操作能否被允许（这个方法将指向Permission对象的引用作为唯一的参数，并返回void。checkPermission方法通过自顶向下查找，只要它遇到一个没有权限的帧（类中的方法），就抛出一个AccessControlEXception异常）。