下载
第3章JDK1.2安全结构
本章主要讨论JDK1.2安全结构的内部机制,它支持策略驱动,基于许可权的,灵活的及可扩展的访问控制.本章将回顾一下Policy和Per
mission类的
设计方法,安全类加载的内部机制及访问控制算法.下面首先概述这种新的结构产生的动机和它的发展历史.
3.1起源
1996年8月底,JDK1.2安全结构开始被酝酿,次年2月开发了相应的代码,3月设计出第一个许可权控制AppletViewerappletviewer原型.1997年5月获得具有完备特性的AppletViewer原型.它们和说明
Java安全新结构的出版物大约同期.在1997年2月的IEEECOMPON[29]会议上,我发表了一篇论文,后来,在IEEEMicro5/6月双月刊[23]上对这篇论文作了一些修改和扩展.1997年4月在JavaOne的讨论中,我可以自信地对手边的原型讲出它们的一些技术细节.在后来的12个月中,安全结构基本保持不变,而API却在不断的精化当中.在1997年12月的USENIX会议上发表了关于API的一个概要性文件[25].1998年初,在一个国际社会专题讨论会上,安全结构的技术细节被发表[28].我们把JDK1.2的安全工程形象地称为"直布罗陀(Gibraltar)",这主要是因为Java安全开发小组人员把它看作是Java技术的重要基石,而且它的顺利完成也颇费周折.目前,开发小组人员正在构想用其他大力神柱(古代称为Abyla,现在称为MountHacho)来命名下一代安全工程.
3.2为什么需要一个新型的安全结构
如在第2章讨论的,由于并没有多少技术人员把安全性作为设计目标,而JDK1.0的发行版着重考虑了安全
问题并提供了沙盒安全模型,所以,可以说正是在Java技术,Internet和电子商务的推动下使安全技术成为
计算机工业的主流,这是一个非常重要的成就.接下来应该改进最初的设计
方案,弥补早期版本中的一些不足之处,使Java平台上的安全解决方案更易于使用,更为强大.3.2.1关于applet的沙盒模型的局限性沙盒模型严格地限制了几种行为,而这些行为applet可以执行.尽管沙盒模型是产生安全
网络计算的必要因素,但它却把所有的applet看成是潜在可疑的.因此,一些applet
程序,例如那些公司财务组编制出的用以处理内部交易的程序,即使它们比从陌生的Web站点随意下载的applet程序可靠许多,但在使用上也要受到限制.像这样对所有的applet的全面限制是有局限性的.例如,假设总部在旧金山的经纪公司CharlesSchwab的一个客户正在运行该公司网页上的applet程序来进行股票交易,他也许想用
Gibraltar一词来源于calpe,两个大力神柱之一,见Brewer'sDictionaryofPhrase&;Fable.
20
使Java2平台安全技术—结构,API
下载
applet更新CharlesSchwab的公事包中的本地文件;不过,沙盒模型禁止访问客户方的文件
系统.因此,这位客户需要灵活的访问控制,某些applet可以访问沙盒以外的东西,或者说,沙盒模型应该可以定制(例如,由客户系统)成灵活的外形和边界.另一方面,这位客户也许会在本地计算机上安装Quicken
软件来处理所得税事务,它也许会感到极不舒服,因为CharlesSchwab的applet可以自由地控制它的整个计算机系统.在这种情况下,最好对applet所能访问的文件系统加以限制,让它只能访问CharlesSchwab文件夹,即就是说,需要"细致的访问控制系统".在JDK1.2之前,Java平台理论上可以获得更为灵活和细致的访问控制.为了具体实现它,一些人(如应用程序员)必须要做大量的编程
工作,例如划分子类和定制SercurityManagerClassL
oader等类.由Sun公司开发的支持Java开发环境的Internet浏览器HotJava便是这样的例子,它提供一系列有限的用户可定义的安全特性.但是,这样的编程工作对安全性极为敏感,需要丰富的计算机安全知识和强大的编程能力.JDK1.2的结构旨在消除编写安全代码的必要.少数情况除外,如在军事环境中,因为它需要特别的安全特性(如多级安全特性)[44].即使在军事环境下,在JDK1.2平台上编写安全代码也会变得更为简便和安全.3.2.2策略和实施分离的不彻底性沙盒模型,由SecurityManager类编码,以软件的形式实现了一种特定的安全策略,而这种软件以实施特定的安全策略为主要目的,这意味着要实施不同的安全策略,必须使用一种特定版本的软件—显然这并不是我们所需要的,相反,我们所需要的是一种支持一系列易于配置的安全策略的底层结构.JDK1.2安全结构清楚地分开了实施机制和安全策略声明.因此,应用程序员和用户无须编写特殊的程序就可以配置自己喜欢的安全策略.3.2.3安全核查的不易扩展性最初的设计使得JDK执行的安全核查难以编写相应的代码.例如,当检查一个文件是否可读打开时,需要调用SecurityManager类中的checkRead()方法.显然,这样的设计方法不适合今后的JDK的新型核查处理,所以它不易扩展.并且,也不易改变规模.例如,为产生一种新型访问核查,如某人去检查钱是否从银行帐户中提出一类的事情,必须要在SecurityManager类或它的子类中增加checkAccoutWithdraw()方法.许多不同目的的核查可能同时存在,如果为这些大量的核查而生成相应的方法,可能会造成SecurityManager类的过度拥挤.事实上,许多核查都是针对特殊应用的,所以并不是所有的核查都可以在JDK内部定义.我们所需要的是一种易于扩展的访问控制结构.JDK1.2结构引入了可定义类型的访问控制许可权和一种自动处理机制来实现可扩展性和规模可改变性.在理论上,SecurityManager类中不需要再加入新的方法.在JDK1.2的发展过程中,当我们引入大量新型安全核查时,并不需要新的方法,一个名叫checkPermission()的方法,已经足以处理所有的安全核查.3.2.4对本地安装的applet过于信任最初的安全模型默认所有本地安装的Java应用程序都是可以完全信任的,应该在最高的