JavaTM安全体系结构 2

最新推荐文章于 2024-11-08 23:31:31 发布

wxyxl

最新推荐文章于 2024-11-08 23:31:31 发布

阅读量976

点赞数

文章标签： applet java jdk 程序开发网络 sun

本文链接：https://blog.csdn.net/wxyxl/article/details/2600

版权

Java^TM安全体系结构（JDK1.2）

2. 新的保护机制──基本概念概述

现在，我们讨论一下新的保护体系结构，并对它的功能性做一个简要的说明。我们将从新体系结构的基本概念说起，然后按自然顺序介绍主要的新类，即先从许可说明开始，然后是策略和有关特性及访问控制和它的使用，最后是安全类装载和解决方案。

一个基本的概念和系统安全性的重要积木是保护域。一个域可通过对象集来划分范围，这些对象当前可由一个主体直接访问。而主体是在计算机系统中被授予许可（许可的结果是可说明的）的实体。JDK1.0所利用的沙箱就是一个有着固定边界的保护域实例。

保护域的概念是一种在保护单元间起着分组和隔离作用的便利机制。例如，我们可以（还没有作为一种内置特性来提供给用户）将保护域分开以避免它们之间的直接交互作用，于是，任何允许的交互作用必须通过可信系统代码或被有关的域所明确允许。请注意，在新的安全体系结构下，现存对象访问规则仍然有效。

保护域通常分为明确的两个类别：系统域和应用程序域。重要的是，所有被保护的外部资源（如文件系统、网络设施以及屏幕和键盘等）仅能通过系统域来访问。下图演示了一个Java应用环境的域的组成。

从概念上讲，一个域包括一组类，这些类的实例被授予相同的一组许可。保护域是由现行策略所确定的。Java应用程序环境保持了来自代码（类和实例）到它们的保护域然后再到它们的许可的映射。如下图所示：

执行的一个线程（它经常是一个单一的Java线程，但也不一定依赖于这个单一的Java线程，也不依赖于底层操作系统的线程概念）可能完全发生在一个单一的保护域中，也可能涉及一个应用程序域或是系统域。例如，一个打印消息的应用程序将不得不与系统域发生交互作用，因为系统域是唯一对输出流的访问点。在次种情况下，无论在任何时候，应用程序域都不能通过调用系统域获得除打印消息外的任何额外许可。这点至关重要。否则，可能会出现严重的安全隐患。

在相反的情形，一个系统域从一个应用程序域中调用一个方法，如当一个AWT系统域调用一个Applet的绘画方法来显示这个Applet时，有效访问权限与应用程序域所允许的当前权限在任何时候都相同，这一点也是同样至关重要的。

换句话说，一个并非"强大"的域不能通过调用一个更强大的域，或被一个更强大的域所调用来获得额外的许可。

上述有关一个线程涉及两个保护域的讨论自然地归纳为一个遍历多重保护域的线程，计算许可的一个简单而谨慎的经验做法是：

一个执行线程的许可集可被认为是由该线程所遍历的所有保护域的许可的交集。
当一条代码调用doPrivileged方法时（见下），执行线程的许可集被认为是包括一个许可，如果该许可被上述代码的保护域所允许并被调用或而后直接、间接进入的保护域所允许的话。

正象你所看到的，通过doPrivileged方法可使一条可信代码能临时访问更多的资源。这在某些情况下是必要的。例如，一个应用程序可能不被允许直接访问包含字体的文件，但是，显示文本的系统实用程序必须代表用户获得那些字体。我们为系统域提供了doPrivileged方法来处理这样的情况，事实上，该方法在所有域中都是可以调用的。

在执行期间，当请求访问一个关键系统资源（如文件I/O和网络I/O）时，资源处理代码直接或间接地调用一个特殊AccessController类的方法，它可评估该请求并决定是否准予该请求。

该评估紧跟在上面提到的"经验做法"之后并概括了该"经验做法"。进行评估的实际做法可由于实现的方法不同而有所变化。其基本原则是检查调用历史和相关保护域的许可，如果请求被准予，则安静地返回，反之，则扔出一个安全异常。

最后，每个域（系统的或应用程序的）也可以对其域边界内的内部资源的进行附加保护。例如，一个银行系统的应用程序可能需要支持并保护其内部的一些概念，如查帐、存款和取款等。由于此种保护的语义一般是不可预测的，JDK也无法实施，因而，在这个等级的保护最好留给系统或应用程序开发员来做。尽管如此，我们仍然愿意在合适的时候为简化程序员的工作而提供一定的方法，其中之一就是SignedObject类，我们稍后再讨论它的细节。

..........|Next|..........