工具软件   办公软件   操作系统   网络安全   设计在线   程序开发   教程宝典   软件下载   软件论坛
您的位置:软件 > 开发者网络 > 开发工具 > Java > 正文
解析Java体系结构对信息安全的支持
[文章信息]
作者:赵熙朝
时间:2005-02-22
出处:天极网
责任编辑:方舟
[文章导读]
Java语言拥有三大特征:平台无关性、网络移动性和安全性……
advertisement
热点推荐
· MFC程序员的WTL指南之包容ActiveX
· 系统安全卫士SPY Destroy
· 绕过身份验证加对方为好友
· 2月21日软件精选 QQ被盗原因及防范
· Visual Basic上机考试综合应用题选讲
[正文]

上一页  1 2 3 4  下一页

  安全管理器

  安全管理器为Java虚拟机的环境建立了一个起到保护作用的"沙箱",这个"沙箱"为程序提供了一个限制了应用的操作运行环境,保护了虚拟机外部的资源不会被虚拟机内部的恶意代码破坏。安全管理器的安全策略可以灵活的建立细粒度的访问控制策略,将不同的资源访问权限授予不同的代码单元,这也是Java体系结构安全模型的最大特点和优势之一。

  首先在赋予权限前我们要明确代码单元的来源,签名担保可以使用户确认文件的来源,并且这些文件在本地虚拟机加载前没有被修改,只有保证了源代码来源的可靠性,才能分配相应的操作权限。对class文件或者jar文件的签名可以用jdk中的jarsigner这个工具。它首先对根据文件内容进行单向散列计算,产生一个散列值,然后把这个散列加到文件后面作为文件的一部分传递给用户,用户收到文件后重新生成一次散列值,然后跟文件后部的散列值进行比较,如果这两个散列值相同说明文件内容没有被改动,虽然不同的文件内容可能生成相同的散列值,但是一般Java采用的是124位散列,这个长度想要从一个不同的输入产生一个已知散列值的计算是不可行的。仅仅通过散列值是没有办法保证代码的来源的,因为怀有恶意的人完全可以把整个文件和散列值都替换掉,为了防止这种事情发生,必须在发送前用私钥对散列值进行加密,为什么不对整个文件进行加密呢,因为jarsigner默认采用的是DES算法,加密本身也是一个费时的过程,我们的目的只是为了保证文件的来源而不是文件本身的保密性,所以只需要对散列值进行加密,用户收到文件以后用文件提供者的公钥进行解密来验证散列值没有被替换。


  明确了代码来源,并且保证没有被修改以后,就可以给它分配操作权限。安全策略是一个java.sercurity.Policy的实现类,Policy中主要包含了代码来源和相应的权限的对应关系信息,安全管理器的check方法将根据Policy对象判断给导入的代码赋予什么样的操作权限。代码来源是由java.security.CodeSource表示的,这个对象中包含了一组Certificate对象,说明了为这个代码文件担保的签名。而权限是用java.sercurity.Permission的子类实例来表示的,每一个Permission有三个属性:类型、名称和可进行的操作,类型说明了权限控制的资源类型,比如FilePermission说明了是对文件操作的权限,名称说明了这个权限控制的对象,比如FilePermission的名称为"/mydoc/order.txt",说明了对文件order.txt的操作权限,可进行的操作属性说明了这个权限可以进行的操作,比如"read"说明这个FilePermission可以对order.txt进行读操作。

  开发人员可以通过编写代码继承SecurityManager类建立自己的安全管理器来设置安全策略,更方便和常用的方法是通过设置策略文件来实现。这是一个策略文件的例子:

//从mykeys文件中获得签名的公钥
keystore "mykeys"
//由father签名的代码赋予读order.txt文件的权限
grant signedBy "father"{
 permission java.io.FilePermission "order.txt","read";
}
//来自{Java_Home}/security/ex/目录下面的所有jar文件和class文件有读写order.txt文件的权限
grant codeBase "file:${Java_Home}/security/ex/*"{
 permission java.io.FilePermission "order.txt","read,write";
}
//来自{Java_Home}/security/ex/目录下面的带有wife签名的所有jar文件和class文件有接受、连接和监听8080端口的权限
grant signedBy "wife" codeBase "file:${Java_Home}/security/ex/*"{
 permission java.io.SocketPermission "*:8080","accept,connect,listen";
}
//所有代码都有读写appversion.properties文件的权限
grant {
 permission java.io.FilePermission "appversion.properties","read,write";
}

  如果一个应用程序没有指定启动安全管理器进行干预,它的所有操作不会受到管理器的限制,指定启动安全管理器有两种方式,一种是在运行应用程序的时候指定,一种是在代码中指定。

java -Djava.serciruty.manager myapplication

  这里指定了启动默认安全管理器,这时候将根据Java默认的全局策略文件来设置安全策略,这个文件是

/JAVA_HOME/lib/security/java.policy。
java -Djava.serciruty.manager -Djava.serciruty.policy=<URL> myapplication

  这里启动安全管理器,除了默认的全局策略文件外,也会按照Djava.serciruty.policy参数指定的策略文件来设置安全策略,文件指定可以用URL也可以直接用文件名称。

  如果是在代码中指定,程序通过setSecurityManager方法设置一个java.lang.SecurityManager的实例时候,这时候安全管理器就会开始控制应用程度的操作了。这时当类加载器加载类到虚拟机的时候,安全管理器根据代码来源和签名找到相应的权限,然后建立这个类的保护域ProtectionDomain,保护域定义了这个类所有的权限。当应用程序用到这个类并要进行任何可能的不安全操作时,都会向安全管理器请求操作许可,安全管理器中有一系列的check方法来检查操作是否可行,比如checkRead方法会检查是否能够读取某个文件,checkWrite方法检查是否能够写入某个文件,管理器根据操作请求类型调用相关的check方法,check方法根据类的保护域判断操作是否可行,如果操作没有权限的话将抛出一个异常,操作收到这个异常后将不能执行,如果操作可行的话,check方法就顺利返回,操作继续执行。

  以上签名验证、定义安全策略以及安全管理器检查操作权限一系列过程,有效的保护了被Java应用使用的外部资源的安全性。要注意的是而由启动类加载器加载的核心API类是不受这个安全管理器的权限控制,这也是为什么要用类加载器防止核心API被恶意代码替换的原因。


上一页  1 2 3 4  下一页

发表评论推荐给朋友我想参加相关培训打印我对此感兴趣订阅电子杂志
相关内容焦点新闻
  • 关于Java栈与堆的思考
  • 大道至简 Java 23种模式一点就通
  • JavaBeans程序开发从入门到精通
  • 使用SWT开发基于Java的图形用户界面
  • Java加密和数字签名编程快速入门
  • 夏普第8代液晶生产动工 下半年将变革策略
  • 手机闲置造成资源浪费 专家呼吁早出台法规
  • IT卖场网站竞争加速 在残酷现实中沉默前行
  • 笔记本市场硝烟再起 家用笔记本年内翻番
  • 信息化时代:谁来保护我们的个人信息?
  • 维权法宝:别让信息化的证据“稍纵即逝”
  • 中国软件三痛之人才篇:外包是“重灾区”
  • 关于我国电子政务建设信息共享策略的反省
  • Advertisement