Java安全体系结构的演变.docVIP

Java安全体系结构的演变 詹剑锋 程虎 中科院软件所(Email: jfzhan@263.net; chenghu@126.net) 论文摘要:本文综述了从JDK1.0到JDK1.4[1-7]，Java安全模型的演化、安全体系结构的演变以及未来的一些方向，重点介绍了新的安全体系结构下的保护机制—保护域（protection domain）的概念。 关键词：安全模型　安全策略　许可权限　保护域　沙箱模型 自Java技术出现以来，对Java平台的安全问题及应用Java技术而产生的安全问题引起的兴趣越来越强，并且持续增长。从JDK1.0到JDK1.4，Java的安全体系结构不断演变，新的安全模型和机制不断提出，而安全性也不断得到加强。 1．安全模型的演变 Java平台提供的最初安全模型为沙箱模型[2]，它为从开放的网络中获取的非信任代码提供了一个受限制的运行环境。沙箱模型的实质是本地代码对重要的系统资源(如文件系统)有全部的访问权限，而下载的远程代码(如applet)则不被信任且仅能访问沙箱里提供的有限资源。沙箱模型如图1所示。 沙箱模型的整体安全通过一系列的机制来实现。 第一、语言被设计为类型安全和容易使用的。这种安全的保障在于与其他语言相比(如C和C++)程序员犯错误的可能性得到减轻。一些诸如自动内存管理、垃圾回收及对字符串列和数组范围检查的语言特性正是这种机制的体现。 第二、编译器和字节码验证器确保了只有合法的Java字节码才被执行。字节码验证器和Java虚拟机一起保证了运行时的语言安全。 第三、更为重要的是类加载器定义了本地名字空间，它防止不被信任的applet干扰其他程序的运行。 最后，对关键系统资源的访问由Java 虚拟机来仲裁，且预先由SecurityManager类来检查，SecurityManager类严格地限制了不信任代码的行为。 JDK1.1引入了“签名applet”的概念，如图2所示。在该版本中，如果签名密匙被接收applet的终端系统识别为被信任的，那么正确被数字化签名的applet将被当做可信任的本机代码一样运行。被签名的applet和它们的签名一起以JAR(Java Archive)的格式发送。在JDK1.1中，未签名的applet仍然运行在沙箱环境中。 JDK1.2中的新安全体系结构如图3所示。引入这种安全体系结构的主要是为了如下目标： 1)细粒度的访问控制：这种能力一开始就存在于JDK中，但使用它需要程序开发人员做大量的编程工作(如通过子类化subclassing和定制SecurityManager和ClassLoader类)。HotJava浏览器1.0正是这样的应用程序，因为它允许浏览器用户选择不同的安全级别。 然而这种编程方法具有极端的安全敏感性，并且要求高超的技术及深度的计算机安全知识。新的安全体系结构使得这个过程比较简单和安全。 2)容易配置的安全策略：这种能力也较早出现在?JDK中且不易使用，更为重要的是编写安全代码并不直观，而让程序开发人员和用户不需要编程只需配置安全策略才是大家期望的。 3)容易扩展的访问控制结构 ：一直到JDK1.1，为了创建新的访问许可权限，需要在SecurityManager类中添加一个new check方法。新的体系结构允许类型化的许可权限(每一个许可权限代表着对一个系统资源的访问)及对正确类型的所有许可权限的自动处理(包括还没有定义的许可权限)。 4)安全检查扩展到所有Java程序 ：不再有内在的“所有本地代码都是可信任”的概念。尽管需要的话可以让本地代码具有最自由的安全政策——使得那些代码完全被信任并且有效地运行，但在新的安全体系结构里，本地代码(如非系统代码、安装在本地的应用程序包)象applet一样受到严格的安全控制。在对安全类(包括SecurityManager和ClassLoader)设计中做内部调整以减少未来编程中存在细小安全漏洞的风险。 2．新的保护机制——基本概念描述 在新的安全体系结构里，最基本的概念和最重要的构造块是保护域(protection domain)。域可以被定义为当前正在被主体(principal)直接访问的一些对象的范围，而主体则是在计算机系统中许可权限(结果主体具有责任性)被授予的实体。JDK1.0中使用的沙箱模型就是一个带固定边界的保护域。 保护域概念可作为在保护单元间成组(grouping)和分隔(isolation)的便利机制。如有可能(但仍然没有作为内建的特性来提供)防止保护域相互交互，这样任何被许可的交互必须要么必须通过被信任的系统代码要么必须显式地被涉及到的域的所容许。而已经存在的对象访问规则在新的安全体系结构下仍然合法。 保护域通常分为两个截然不同组：系统域和应用