Java Security Architecture--Java安全体系技术文档翻译(一)

返回目录

一 介绍

自从Java技术出现以来，关于Java平台本身的安全问题以及Java技术实施过程中引起的新的安全问题引起了大家强烈而持续增长的关注。
从一个技术提供者的角度来看，Java安全包括了两个方面：

• 提供一个安全的、准备好的Java平台，在该平台上可以以一种安全的方式来运行Java程序。
• 提供可在Java编程语言中使用的安全工具和服务，这些工具和服务可以支撑更大范围的对安全敏感的应用，例如在企业级应用领域。

本文档只讨论第一个方面相关的问题，此方面技术的客户包括那些将Java技术捆绑或嵌套到他们自己的产品（例如浏览器和操作系统）中的提供商。

1.1 原始的沙盒模型

Java平台一开始提供的安全模型作为沙盒模型（sandbox model）而广为人知，该模型旨在提供一个对于从网络上获取的非信任代码的非常严格的校验环境。sandbox模型的实质就是：本地代码是被信任的，对于系统资源（例如文件系统）有所有的访问权限；同时下载的远程代码（applet）是不被信任的，只能访问沙盒内部允许的有限资源。沙盒模型如下图所示：

沙盒模型随着JDK一起部署，在用JDK1.0构建的程序中被广泛采纳，也包括支持Java的web浏览器。
整体安全性通过一系列机制来强制实施。首先，Java语言被设计成类型安全并易于使用的。期望的效果是程序员的负担变小以至于他们犯难以察觉错误的概率相较于使用其他编程语言例如C或C++会降低。像内存管理、垃圾回收、字符串和数组越界检查等安全特性就是Java语言帮助程序员编写安全代码的典型例子。
其次，编译器和字节码校验器确保只有合法的Java字节码会被执行。字节码校验器，伙同Java虚拟机，保证了运行时的语言安全性。
此外，一个classLoader定义了一个局部命名空间，可用来确保不被信任的代码不能干扰到其他程序的运行。
最后，对于系统的关键资源的访问，由Java虚拟机来做居间调节，由SecurityManager做进一步的检查，SecurityManager将一段不被信任的代码的行为限制到最少。
JDK1.1引进了“签名程序”的概念，像下图展示的一样。在这个版本下，如果代码片段的签名密钥被收到它的终端系统识别为可信任，那么该签名的代码就会和本地代码一样受信任。签名代码，连同它们的签名，使用JAR格式被传递。在JDK1.1,未签名的远程代码（applet）仍然在沙盒中运行。

1.2 沙盒模型的进化

新的Java SE平台安全体系，如下图所示，因为下面列出的目的而被引入。

• 粒度划分良好的访问控制

这个能力JDK从一开始就有，但是程序开发者需要做大量的编程才能做到（例如：通过继承及定制SecurityManager和ClassLoader类）。HotJava browser1.0就是这样一个程序，它允许浏览器使用者在一小部分不同的安全级别中做选择。
然而，这样的编程对安全非常敏感并且要求有高超的技巧和对计算机安全有深入的理解。新的安全体系会使其变得更简单和更安全。

• 可轻松配置的安全策略

再一次，JDK原本就有这个能力，但是不太容易使用。此外，编写代码来实现安全策略并不直接，所以允许应用开发者和使用者无需编程也能配置安全策略会非常有吸引力。

• 易于扩展的访问控制体系

在JDK1.1中，为了创建一个新的访问许可（access permission），你需要为SecurityManager添加一个新的check方法。新的安全体系允许类型化的许可（每一条代表对系统资源的一个访问权限），并能自动处理正确类型的所有许可（包括尚未定义的许可）。在绝大部分情况下不需要为SecurityManager添加新方法。（实际上，我们到现在为止都没碰到必须增加新方法的情况）

• 将安全检查扩展到所有的Java程序，不只是applets

不再有本地代码都会被信任这样想当然的概念了。取而代之，本地代码（例如：非系统代码，本地文件系统上的应用包）和applet使用同样的安全控制，虽然说如果需要，仍然可以将本地代码（或者远程代码）声明成有最大自由，这样这些代码会像是被完全信任一样运行。对于签名applet和任何Java程序，该原则同样适用。

最终，一个隐含的原因是对安全相关类（包括SecurityManager和ClassLoader类）进行内部的调整修改，以此来减少在未来编程中造成不易察觉的安全漏洞的风险。

二 新保护机制 -- 基本概念概览

我们现在在一些细节上重温一下新的保护体系，并对其功能进行一个简要说明。我们从新体系背后的基本概念概览开始。然后以一个自然的顺序介绍主要的新增类，从许可（permission）描述开始，然后继续到规则（policy）及其相关特征，跟着是访问控制（access control）和它的用处，最后涵盖类解析和加载中的安全。
一个基本概念和系统安全的重要组成部分就是保护域（protection domain）。一个域可以由一个当事人身份（principal）可直接访问的一组对象来界定，当事人身份（principal）就是在计算机系统中许可（以及由此产生的责任）被赋予或绑定的实体。JDK1.0使用的沙盒就是一个有固定边界的保护域的例子。
保护域概念为各保护单元的聚合和隔离提供了一个方便的机制。 例如，可以实现（但尚未作为一个内置的特性提供）将相互交互的保护域分开，这样一来任何被许可的交互都必须要么通过被信任的系统代码完成要么被相关保护域明确的允许。注意到已存在的对象访问规则在新安全体系下仍然有效。
保护域主要分为两种不同的类型：系统域和应用程序域。重要的是所有的受保护的外部资源只能通过系统域访问，这些资源包括文件系统、网络、屏幕和键盘等。下图展示了Java应用程序环境中保护域的结构。

一个域从概念上包括了一组类，这些类的实例都被赋予了相同的一组许可（permission）。保护域是由当前使用的规则（policy）所决定的。Java应用环境保持了一个从代码（类和实例）到他们的保护域再到他们的许可（permission）这样一个路径，像下图所示：

一个执行线程（经常但不一定会绑定到一个单独的Java thread, 这个Java thread也不是一定会绑定到操作系统中的线程概念）可能会完全发生在一个单独的保护域中，或者可能同时涉及到应用程序域和系统域。例如，一个打印消息的程序会和系统域交互，因为只有通过系统域才可以访问输出流。在这种情况下，在任何时候应用程序域都不能通过调用系统域来获得额外的许可，这件事就变得很重要了。否则可能会有严重的安全隐含漏洞。
反过来讲，当一个系统域调用一个应用程序域的方法时，例如当AWT系统域调用一个applet的paint方法来展示该applet，在任何时候保持实际起作用的访问许可和应用程序域激活的当前许可相同，都是至关重要的事情。
换句话说，一个不怎么“强大”的域不能通过调用较“强大”的域或者被较“强大”的域调用来获得额外的许可。
这里关于一个线程涉及到两个保护域情况的讨论自然可以适用到一个线程跨越多个保护域的情况。一个简单又聪明的计算许可的指导规则如下：

• 一个执行线程的许可集合被认为是该执行线程所跨越的所有保护域的许可集合的交集。
• 当一段代码调用了doPrivilege方法（看下面），如果该行为被这段代码的保护域许可，并被其直接或间接调用或进入的所有保护域所许可的话，执行线程的许可集合被认为是直接包含了一个许可。

如你所见，doPrivilege方法允许一段受信任的代码暂时拥有比调用它的应用更多的资源访问许可。这在某些情况下是很有必要的。例如，一个应用可能没有直接访问包含字体的文件的许可，但是站在用户的角度讲，展示文档的系统功能必须要获得这些字体。我们为系统域提供doPrivileged方法来处理这种情况，实际上这个方法在所有的保护域中都可使用。
在执行过程中，当要访问一个关键的系统资源（如文件I/O和网络I/O）时，资源处理代码直接或间接的调用一个特殊的AccessController类方法，该方法评估资源访问请求并决定是允许还是拒绝。
该评估遵循并推广上面给出的“指导规则”。但评估实施的具体步骤在各实现中可能会有不同。基本的方针是检查调用历史及其对应的保护域赋予的许可，如果最终请求被许可，则默默返回；如果最终被拒绝，则抛出一个安全异常。
最后，每一个域（系统的或是应用程序的）可能还需要对自己的域边界范围内的资源实现额外的保护。例如，一个银行系统可能需要支持并保护像账户检查、储蓄和提现等这些内部概念。由于这种保护的语义不太可能被Java2 SDK提前描述或者强制规范，因此在这个层次上的保护系统最好是由系统或应用的开发者来实现。然而，无论何时只要合适，我们都会提供原生的功能来简化开发者的工作。一个这种原生功能就是签名对象类，我们将在后面描述其细节。

===========================================================================

本技术文档的翻译工作由不动明王1984独自完成，特此声明。

翻译辛苦，珍惜劳动，引用时请注明出处！

===========================================================================

返回目录

下一篇：Java Security Architecture--Java安全体系技术文档翻译(二)