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

返回目录

七 GuardedObject和SignedObject

7.1java.security.GuardedObject和java.security.Guard

回顾当需要在另外一个上下文中做出访问控制决策时，AccessControlContext类提供了很大的帮助。有另外一种场景，资源的提供者和资源的消费者不在同一个线程中，并且资源消费者无法提供访问控制上下文信息给资源提供者（由于上下文是安全敏感的，或上下文太大而无法传递，或其他原因）。在这种情况下，我们提供了一个叫GuardedObject的类来保护对资源的访问，如下图所示。

基本的想法是资源提供者可以创建一个代表该资源的对象，并创建一个GuardedObject嵌入到资源对象里，然后将GuardedObject提供给消费者。在创建GuardedObject时，提供者同时指定了一个Guard对象，如此一来任何人（包括消费者）只有在满足了Guard中的特定安全检查以后才能获得资源。
Guard是一个接口，因此任何对象都可以选择成为一个Guard。该接口唯一的方法叫做checkGuard。它有一个Object类型的参数并执行某些（安全）检查。java.security包中的Permission类实现了Guard接口。
例如，假设一个系统线程被请求以读权限打开一个文件/a/b/c.txt，但是系统线程不知道请求者是谁或者是在什么样的环境下做出请求的。因此，在服务端就没法做出正确的访问控制决定。服务线程可以使用GuardedObject来将访问控制检查推迟，像下面一样。

FileInputStream f = new FileInputStream("/a/b/c.txt");
FilePermission p = new FilePermission("/a/b/c.txt", "read");
GuardedObject g = new GuardedObject(f, p);

现在系统线程可以将g传给消费者线程。消费者线程可以使用下面的语句来得到文件输入流

FileInputStream fis = (FileInputStream) g.getObject();

该方法相应的调用Guard对象p的checkGuard方法，因为p是一个Permission，它的checkGuard方法实际上是：

SecurityManager sm = System.getSecurityManager();
if (sm != null) sm.checkPermission(this);

而这确保了在消费者线程中发生正确的访问控制检查。实际上，很多情况下可以把经常用到的哈希表和访问控制列表替换掉，简单的保存一个GuardedObject的哈希表。
这个GuardedObject和Guard的基本模式是非常通用的，我们希望开发者可以通过扩展基本的Guard和GuardedObject类来获得非常强大的权限控制工具。例如，方法级的安全控制可以通过为每个方法创建合适的Guard来实现，也可以有一个Guard检查当天的时间，调用者的签名或其他身份证明，或其他相关信息。
注意由于GuardedObject返回一个Object，因此有一些类型信息会丢失。GuardedObject是要用在相互合作的双方之间，因此接收的一方应该知道它想要的对象的类型是什么（然后做类型转换）。实际上，我们预见到绝大部分对于GuardedObject的使用都涉及到继承它（例如构建一个GuardedFileInputStream类），这样的话就会囊括类型的信息，使得在子类中更舒服的执行类型转换。

7.2 java.security.SignedObject

本类对于其他安全特征来说是一个至关重要的构成部分。SignedObject包括另外一个可序列化的对象，（要被）签名的对象和它的签名。如果签名不为空，它就包含了一个对签名对象的有效数字签名。如下图所示。

潜在的签名算法是通过调用sign方法时传递的一个Signature对象参数来设置的，其中的算法可能是，NIST标准DSA, 使用DSA和SHA-1。在各签名之间，算法使用相同的命名惯例来指定，例如"SHA/DSA"。
签名对象是对原始对象的“深拷贝”（以可序列化的形式）。一旦拷贝完成，对原始对象的进一步操作就无法影响到拷贝了。签名对象是不可改变的。
一个创建签名对象的典型例子如下：

Signature signingEngine =
    Signature.getInstance(algorithm,provider);
SignedObject so =
    new SignedObject(myobject, signingKey, signingEngine);

一个核实签名对象的典型例子如下，如果算法的名字已经知道的话就不需要第一句了：

String algorithm = so.getAlgorithm();
Signature verificationEngine =
    Signature.getInstance(algorithm, provider);
so.verify(verificationEngine);

SignedObject可能的应用包括：

• 它可以在任何Java应用环境的内部作为一个不可伪造的授权令牌使用--可以被传递并无需担心在无察觉的情况下被篡改。
• 它可以用来签名并序列化数据/对象，用于在Java运行时之外的存储（例如，将重要的访问控制数据保存到硬盘）。
• 嵌套签名对象可以用于构建一个签名的逻辑序列，类似于一个授权和委托链。

未来，本类打算可以被继承以允许对于同一个签名对象实现多重签名。在那种情况下，基类中存在的方法将会充分的语义兼容。特别地，如果只有一个签名则每个get方法都会返回唯一的值，如果有多个签名则会随机返回签名集合中的一个。

八 讨论和未来方向

8.1 资源消费管理

资源消费管理在一些情形中是相对简单的（例如，限制应用可以同时打开窗口的个数），同时在另外一些情形中可以非常难（例如，限制资源或文件系统的使用）。我们计划在未来统一解决这样的问题。

8.2 许可的随意组合

有时候将一些许可组合在一起并使用一个速记名来引用它们会很方便。例如，如果我们希望有一个叫做“SuperPermission”的许可，该许可包括了FilePermission("-", "read,write")和SocketPermission("*", "connect,accept")，技术上我们可以使用Permissions类或者一个相似的类来实现这个SuperPermission，通过使用add方法将要求的许可都添加进来。这样的组合可以被随意的构建。
接下来的问题更加困难。首先，当如此一个super permission给出以后，应如何理解其实际的许可，要么创建一个固定且命名的许可类来代表这组静态指定的许可，要么需要在规则文件中阐明这组许可的所有成员。第二，对规则文件的处理可能变得更加复杂，因为组合权限可能需要扩展。此外，嵌套的组合权限会增加更大的复杂性。

8.3 对象级别的保护

考虑到Java编程语言的面向对象特性，可知开发者可以从一组合适的对象级别的保护机制中获益，该机制（1）超出Java编程语言提供的自然的保护机制（2）并对基于线程的安全访问机制做出增补。
SignedObject是一个这样的机制，可以强制在一个每类/对象每方法的级别实现访问控制。然而，这个方法应该不是普遍的，部分因为这种类型的控制不太容易被高效的管理。

8.4 安全域细分

当前没实现但是可能很有用的概念是“子域”。一个子域是一个包含在其他域中的域。子域不能拥有比它所在的域更多的许可或权限。子域被创建来实现应用程序可以做到的非普遍的深入限制。
一个域通常被认为是支持遗传的：一个子域将自然的继承父域的安全属性，除非在某些特定的场景下父域明确削减子域的权限。根据可信任代码的意见适当放松对子域的权限束缚也是可能的。
为了便利，我们可以把系统域想象成一个单个的，包含了所有系统代码的大集合。然而为了更好的保护，系统代码需要运行在不同的系统域上，每一个域都保护一个特定类型的资源并被赋予一个特定的许可集合。例如，如果文件系统代码和网络系统代码运行在不同的域中，前者无法访问网络资源，后者无法访问文件系统资源，一个系统域中的风险及其造成的结果或者安全缺陷就更有可能被限定在它自己的边界中。

8.5 运行签名的Applet

JAR和Manifest代码签名规范允许一个非常灵活的格式。在相同存档中的类文件可以使用不同的密码签名，并且一个类可以无签名，用一个密钥签名，或用多个密钥签名。存档中的其他资源，例如音频剪辑和图片，也可以被签名或无签名，像类文件一样。
这个灵活性给解释时带来了问题。下列的问题需要被回答，特别是当密钥被不同对待的时候：

1. 需要要求图片和音频使用相同的密钥签名吗，如果存档中的所有类文件都被签名了？
2. 如果图片和音频使用不同的密钥签名，他们可以被放进同一个appletviewer（或浏览器），还是需要被送到不同的的viewers执行？

这些问题不太容易回答，并且要求跨平台和产品的一致性才能最有效果。我们中期解决方案是提供一个简单的答案——所有图片和音频会在相同的applet类加载器中处理，无论它们是否签名。一旦一致性问题解决了，这个临时方案会被改良。
此外，如果由于一个类文件的字节码内容与JAR中签名的哈希值不匹配而导致数字签名不能被证实，一个安全异常会被抛出，因为很明显JAR包作者的意图被篡改了。以前会建议以不信任的方式运行这种代码。这种想法在现在是不可取的，因为applet类加载器允许加载多个签名方签名的代码。这意味着如果接受了一个被篡改的JAR文件，这将允许不被信任的代码可以与相同类加载器加载的其他代码运行在一起并访问它们。

九 总结

该文档提供了Java SE平台上使用的主要安全特性的概览，介绍了其使用动机和新的安全体系架构。

十 感谢

略

十一 参考

M. Gasser. Building a Secure Computer System. Van Nostrand Reinhold Co., New York, 1988.
L. Gong, "Java Security: Present and Near Future". IEEE Micro, 17(3):14--19, May/June 1997.


L. Gong, T.M.A. Lomas, R.M. Needham, and J.H. Saltzer, "Protecting Poorly Chosen Secrets from Guessing Attacks". IEEE Journal on Selected Areas in Communications, 11(5):648--656, June, 1993.


J. Gosling, Bill Joy, and Guy Steele. The Java Language Specification. Addison-Wesley, Menlo Park, California, August 1996.


A.K. Jones. Protection in Programmed Systems. Ph.D. dissertation, Carnegie-Mellon University, Pittsburgh, PA 15213, June 1973.


B.W. Lampson. Protection. In Proceedings of the 5th Princeton Symposium on Information Sciences and Systems, Princeton University, March 1971. Reprinted in ACM Operating Systems Review, 8(1):18--24, January, 1974.


T. Lindholm and F. Yellin. The Java Virtual Machine Specification. Addison-Wesley, Menlo Park, California, 1997.


P.G. Neumann. Computer-Related Risks. Addison-Wesley, Menlo Park, California, 1995.


U.S. General Accounting Office. Information Security: Computer Attacks at Department of Defense Pose Increasing Risks. Technical Report GAO/AIMD-96-84, Washington, D.C. 20548, May 1996.


J.H. Saltzer. Protection and the Control of Information Sharing in Multics. Communications of the ACM, 17(7):388--402, July 1974.


J.H. Saltzer and M.D. Schroeder. The Protection of Information in Computer Systems}. Proceedings of the IEEE, 63(9):1278--1308, September 1975.


M.D. Schroeder. Cooperation of Mutually Suspicious Subsystems in a Computer Utility. Ph.D. dissertation, Massachusetts Institute of Technology, Cambridge, MA 02139, September 1972.


W.A. Wulf, R. Levin, and S.P. Harbison. HYDRA/C.mmp -- An Experimental Computer System. McGraw-Hill, 1981.

十二 修订历史

略

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

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

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

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

返回目录

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