首页 安全基础 网络安全 安全协议 病毒分析 防火墙 OS安全 无线安全 Web安全 PKI与PMI 入侵检测 经典案例
安全审计 设备安全 安全管理 安全标准 法律法规 隔离网闸 DB安全 XML安全 开源项目 资源下载 安全论坛 备份恢复
 当前位置:首页>>WEB安全>>java安全>>正文
JavaTM安全体系结构 8
文章出处:www.yestar2000.com 作者:wxyxl   发布时间:2004-09-05   点击:0
 

JavaTM安全体系结构(JDK1.2)


8. 未来发展方向

  8.1 用户、认证和信任书
今天,主体(例如:用户)的概念已经不太清楚了,因为每个JVM都由一个用户所拥有。将来,有必要扩展ProtectionDomain的现存概念以包括"代表一个主体运行"的概念。

因此,我们热切地期望在不远的将来为你提供如下特性:
明确的主体的概念和类

用户认证原语(既有基于口令的, 也是其它的)

交叉保护域主体认证协议


认证和授权一般机制

  8.2 资源消费管理

在某些情况下, 资源消费管理相对容易实现(例如, 限制任何应用程序可能突然出现的窗口数量); 而在某些其它情况下, 它又是相当难以有效实现的(例如, 限制内存或文件系统的使用)。将来, 我们要不断地研究这个问题。

  8.3 随机许可的分组

有时将一些许可组合在一起并使用速记名来引用它们可简化我们的工作。例如, 我们想要使一个被称作"SuperPermission"的许可包括(并隐含)FilePermission("-", "read,white")和SocketPermission("*","connect,accept"), 从技术上讲, 我们可以使用类Permission或一个相似的类用add方法来增加所需要的类, 从而实现这个超级许可。这样的分组可以是任意复杂的。


更困难的事情是: 第一, 要理解在发出这样一个超级许可时, 实际上是授予了一个什么样的许可, 因此就必须创建一个固定的、并且是命名的许可类, 来表示一个静态指定的许可组; 或者就需要在策略文件中详述这些成员的许可; 第二, 由于分组的许可可能需要被扩展, 所以处理策略(文件)可能更复杂; 第三, 分组许可的嵌套也进一步增加了复杂性。

  8.4 对象级保护


假设已给定Java编程语言的面向对象的特性,则可以想象,开发人员将会从一整套适当的对象级保护机制中获得好处。这种对象级保护一是可以超越有Java编程语言所提供的自然保护;二是可以补充基于线程的访问控制机制。


一个这样的机制是SignedObject。我们将提供对象SealedObject,它使用加密技术来隐藏对象的内容, 它与SignedObject相并行(由于美国现行出口控制条例对加密使用上的限制,SealedObject可能将与JDK分开提供)。


GuardedObject是在每个类/对象每个方法等级上加强访问控制的一般途径。然而,这个方法应该仅被选择性地使用,部分原因是这种控制类型在高层上是难于管理的。

  8.5 创建保护域的子域


一个在当前未实现的潜在而有用的概念是"子域"的概念。一个子域被包含在另一个子域中。一个子域的许可和特权不会比它的父辈域的许可和特权多。例如,可创建一个域,以选择性地进一步限制一个程序应该做什么。


域经常被认为是支持继承的:一个子域将自动继承其父辈域的安全属性,除非在某种情况下,父辈域要明显地限制子域。用可信码的概念,通过权力放大,有可能放宽对子域的限制。


为方便起见,我们可以将系统域当作一个单独的、所有系统代码的一个大的集合。然而,为了更好的保护,系统代码应该运行在多个系统域中,每个域保护一个特殊资源类型并被赋予一些特殊的权力。例如,如果文件系统代码和网络系统代码运行在各自的域中,则前者无权访问网络系统的资源,后者也无权访问文件系统的资源。这样一个错误或安全性缺陷所造成的风险和后果将被限制在它自己的域中。

  8.6 运行有签字内容的Applets


有关代码签字的JAR和Manifest规范允许非常灵活的形式。在相同文档中的类可用不同的密钥签字,并且一个类可用一个密钥来签署、解除签字,或用多个密钥签字。在文档中的其它资源(如音频剪辑和图形图象等)也可被签字或解除签字。


与这种灵活性随之而来的是如何解释的问题。下列问题 需要被回答,特别是当密钥被区别对待时:


    1. 如果在文档中的任何类被签字的话,图象和音频数据是否应该用相同密钥签署?


    2. 如果图象和音频被使用不同的密钥签字,它们是否可被放置在相同的appletviewer(或浏览器页)中,或者是否应该被发送到不同的viewer中进行处理?



这些问题并不容易回答,它们需要相容性交叉平台及最有效的产品。我们的折中的方案是要提供一种简单的答案──将所有图象和音频送到相同的Applet类装载器中进行处理(无论它们是签字的或未签字的)。一旦上述问题被达成共识,则这个临时的解决方案将被改进。


再有,如果一个数字签字由于一个类文件的字节码内容与已签字的JAR哈希值不匹配而不能被验证,则一个安全异常被扔出,因为JAR作者的最初意图被明显地改变了。以前,有人建议将这些代码当作不可信代码来运行。这种想法是不受欢迎的。因为Applet类装载器允许装载由多方签字的代码。这意味着接受部分更改的JAR文件将允许一条不可信代码与相同的类装载器共同运行并通过同一类装载器访问其它代码。

9 结束语

本文概述了JDK1.2实现的主要安全特性的生成动机并介绍了这种新的安全体系结构。


请将你的评价反馈给 java-security@java.sun.com (它被存档的web地址为: http://java.sun.com/security/hypermail/
java-security-archive/index.html )。 如需保密请直接发送至作者本人(li.gong@sun.com)。


 

 

作者:
[返回顶部↑]  [推荐好友] [查看评论]  
用户名: 新注册) 密码: 匿名评论 [查看评论]  发表评论
评论内容:(不能超过250字,需审核后才会公布,请自觉遵守互联网相关政策法规。
 
↑文章搜索
  关键字:  
  范  围:  
  开始搜索  
※相关文章※
 

◎ 企业内部网中使用
◎JavaTM安全体系结构
◎ 利用 Web 对象通
◎JavaTM安全体系结构
◎再探JSP的安全性——Write

 
※热点文章※
  ·再探JSP的安全性——Write
·JavaTM安全体系结构
· 利用 Web 对象通
·JavaTM安全体系结构
· 企业内部网中使用
· 如何使java Appl
· 如何保护Java程序
 

关于我们 | 征搞启示 | 版权信息 | 联系我们 | 友情链接

版权所有:中国信息安全组织 © 2003-2005 Power by DedeCms