8 问题讨论及未来发展方向
8.1 用户、认证和证书
现在主体（如用户）是隐含的，这是因为每个 JVM 均被一个用户拥有。将来，有必要将已有的 ProtectionDomain 概念扩展为包含“代表主体运行”的概念。 因此，我们期望在不久的将来能提供如下功能：显式的主体概念和类
用户认证基本方式 (基于口令的认证方式及其它方式)
跨保护域主体认证协议
授权和代理一般机制
8.2 资源消耗管理
资源消耗管理在某些情况下相对比较容易实现（例如，限制应用程序在任一时候可弹出的窗口数量），但在其它情况下很难有效地实现（例如，用来限制内存或文件系统的使用）。我们计划未来继续从事此类问题的研究.8.3 权限的任意分组
有时将许多权限放在一个组中并用简称来指称它们较为方便。例如，如果希望名为“SuperPermission”的权限包括（并隐含）FilePermission("-", "read,write") 和 SocketPermission("*", "connect,accept")，从技术上来说，可通过用 add（添加）方法添加所需权限来用类 Permissions 或相似的类来实现此超级权限。这种分组可以任意复杂化。 下面有一些较难的问题。首先，为理解当给出这样的超极权限时实际上已授予哪些权限，需创建一个固定且已命名的权限类来代表静态指定的权限组，或在策略文件中清楚地说明成员权限。其次，处理策略（文件）会更加复杂，因为分组权限可能需要扩展。此外，分组权限的嵌套进一步增加了复杂度。8.4 对象级的保护
由于 Java 编程语言本质上是面向对象的，因此我们确信开发人员将会从一套对象级保护机制中获益，这套对象级保护机制：(1) 超越了 Java 编程语言提供的固有保护，(2) 补充了基于线程的访问控制机制。 其中一种机制是 SignedObject。与这种原语相应，我们将提供 SealedObject，它使用加密来隐藏对象的内容（限于现在美国在使用加密方面的出口控制规定，SealedObject 类将有可能与 JDK 分开而单独提供）。 GuardedObject 是逐类/对象逐方法强制进行增强访问控制的一般方式。但这种方法应有选择地使用，部分原因是此类控制很难在高级别上进行管理。8.5 细分保护域
一个可能有用但现在尚未实现的概念是“子域”。子域是包含在另一域中的域。子域的权限或特权不会比将其作为元件的域所拥有的更多。例如，可以创建域来有选择地进一步限制应用程序可以做的事情。 通常认为域支持继承：除在有些情况下父域进一步显式地限制了子域外，子域将自动继承父域的安全属性。如果引入了信任代码的概念，则通过适当的权利放大来放松子域是可能的。 为方便起见，我们可以认为系统域是一个所有系统代码的大集合。但是，为了更好地进行保护，系统代码应该在多个系统域中运行，其中每个域保护特定类型的资源，同时得到一套特殊权限。例如，如果文件系统代码和网络系统代码在不同的域中运行，其中前者没有访问网络资源的权限，而后者没有访问文件系统的权限，则一个系统域的错误或安全漏洞将被最大可能地限制在其范围之内。8.6 运行带有已签名内容的 Applet
有关代码签名的 JAR 和“清单”规范允许非常灵活的格式。同一归档中的类可以用不同密钥签名，并且类可以被不签名、用一个密钥签名或用多个密钥签名。和类一样，归档内的其它资源（如音频剪辑和图形图像）也可以被签名或不签名。 这种灵活性可能引起解释方面的问题。需要解答下列问题（尤其是当密钥以不同方式处理时）：1. 如果在归档内有类被签名，则图像和音频是否需要使用
相同密钥签名？
2. 如果图像和音频使用不同的密钥签名，则
它们是否可以放在相同的 appletviewer（或浏览器页）中
还是应该发送到不同的查看器进行处理？
这些问题回答起来并不容易，而且要求跨平台的一致性和最有效的结果。我们的折衷方法是提供一个简单的答案 -- 所有图像和音频剪辑都送到相同的 applet 类加载器中处理，而不管它们是否被签名。在达成一致后，这种临时解决方案将会得到改进。 此外，如果由于类文件的字节码内容与 JAR 中的签名散列值不同而导致数字签名无法校验，就将产生安全异常，因为 JAR 作者的原始意图被明显更改。以前有人建议将这种代码作为不信任代码运行。这种方法不可取，因为 applet 类加载器允许加载多方签名的代码。这意味着接受部分修改的 JAR 文件将允许不信任代码一起运行并通过同一类加载器访问其它代码。
8.1 用户、认证和证书
现在主体（如用户）是隐含的，这是因为每个 JVM 均被一个用户拥有。将来，有必要将已有的 ProtectionDomain 概念扩展为包含“代表主体运行”的概念。 因此，我们期望在不久的将来能提供如下功能：显式的主体概念和类
用户认证基本方式 (基于口令的认证方式及其它方式)
跨保护域主体认证协议
授权和代理一般机制
8.2 资源消耗管理
资源消耗管理在某些情况下相对比较容易实现（例如，限制应用程序在任一时候可弹出的窗口数量），但在其它情况下很难有效地实现（例如，用来限制内存或文件系统的使用）。我们计划未来继续从事此类问题的研究.8.3 权限的任意分组
有时将许多权限放在一个组中并用简称来指称它们较为方便。例如，如果希望名为“SuperPermission”的权限包括（并隐含）FilePermission("-", "read,write") 和 SocketPermission("*", "connect,accept")，从技术上来说，可通过用 add（添加）方法添加所需权限来用类 Permissions 或相似的类来实现此超级权限。这种分组可以任意复杂化。 下面有一些较难的问题。首先，为理解当给出这样的超极权限时实际上已授予哪些权限，需创建一个固定且已命名的权限类来代表静态指定的权限组，或在策略文件中清楚地说明成员权限。其次，处理策略（文件）会更加复杂，因为分组权限可能需要扩展。此外，分组权限的嵌套进一步增加了复杂度。8.4 对象级的保护
由于 Java 编程语言本质上是面向对象的，因此我们确信开发人员将会从一套对象级保护机制中获益，这套对象级保护机制：(1) 超越了 Java 编程语言提供的固有保护，(2) 补充了基于线程的访问控制机制。 其中一种机制是 SignedObject。与这种原语相应，我们将提供 SealedObject，它使用加密来隐藏对象的内容（限于现在美国在使用加密方面的出口控制规定，SealedObject 类将有可能与 JDK 分开而单独提供）。 GuardedObject 是逐类/对象逐方法强制进行增强访问控制的一般方式。但这种方法应有选择地使用，部分原因是此类控制很难在高级别上进行管理。8.5 细分保护域
一个可能有用但现在尚未实现的概念是“子域”。子域是包含在另一域中的域。子域的权限或特权不会比将其作为元件的域所拥有的更多。例如，可以创建域来有选择地进一步限制应用程序可以做的事情。 通常认为域支持继承：除在有些情况下父域进一步显式地限制了子域外，子域将自动继承父域的安全属性。如果引入了信任代码的概念，则通过适当的权利放大来放松子域是可能的。 为方便起见，我们可以认为系统域是一个所有系统代码的大集合。但是，为了更好地进行保护，系统代码应该在多个系统域中运行，其中每个域保护特定类型的资源，同时得到一套特殊权限。例如，如果文件系统代码和网络系统代码在不同的域中运行，其中前者没有访问网络资源的权限，而后者没有访问文件系统的权限，则一个系统域的错误或安全漏洞将被最大可能地限制在其范围之内。8.6 运行带有已签名内容的 Applet
有关代码签名的 JAR 和“清单”规范允许非常灵活的格式。同一归档中的类可以用不同密钥签名，并且类可以被不签名、用一个密钥签名或用多个密钥签名。和类一样，归档内的其它资源（如音频剪辑和图形图像）也可以被签名或不签名。 这种灵活性可能引起解释方面的问题。需要解答下列问题（尤其是当密钥以不同方式处理时）：1. 如果在归档内有类被签名，则图像和音频是否需要使用
相同密钥签名？
2. 如果图像和音频使用不同的密钥签名，则
它们是否可以放在相同的 appletviewer（或浏览器页）中
还是应该发送到不同的查看器进行处理？
这些问题回答起来并不容易，而且要求跨平台的一致性和最有效的结果。我们的折衷方法是提供一个简单的答案 -- 所有图像和音频剪辑都送到相同的 applet 类加载器中处理，而不管它们是否被签名。在达成一致后，这种临时解决方案将会得到改进。 此外，如果由于类文件的字节码内容与 JAR 中的签名散列值不同而导致数字签名无法校验，就将产生安全异常，因为 JAR 作者的原始意图被明显更改。以前有人建议将这种代码作为不信任代码运行。这种方法不可取，因为 applet 类加载器允许加载多方签名的代码。这意味着接受部分修改的 JAR 文件将允许不信任代码一起运行并通过同一类加载器访问其它代码。
谢谢！ [email protected]