第九章 CLR 中代码访问安全检测实现原理.docVIP

在传统的操作系统级安全模型中，安全管理的粒度都是 Principal-based 层面的。用户从认证登陆成功开始，就获得此帐号的所有权 限，而其运行的程序，也自动被授予帐号及其所在组的所有权限。例如我在《DACL, NULL or not NULL》一文中介绍的，NT 用户从登陆到系统 建立 Session 开始，就缺省使用相同权限，新建进程自动获得父进程的权限，除非程序本身手动进行限制。而 *nix 系统下面的思路也是类似 ，只不过从 Token 编程了各种 uid/gid 等等。 　　这种 Principal-based 的安全模型，在以主机为中心的孤立环境中是非常合适的，而且足够简单和高效。但随着网络的普遍使用，这种安 全模型开始受到挑战，最直接的就是如何处理从网络上运行程序的策略问题。按照现有模型，所有程序都会自动获得最大权限集，但这显然是 不现实的，安全管理粒度过于粗放。 　　因此在 Java 和 IE 等涉及网络的应用程序中，提出了新的基于位置的安全模型。一个程序运行时获得的权限，并不由其父进程或者说宿 主来决定（这些程序往往用于较高权限），而是由其程序所在位置觉得具有多少权限。Java 中将之简化为对代码源的安全策略限定，如在策略 文件中指定所有来自 的程序都有写 c:\temp 目录的权限，而来自其他网址的程序只能读取 c:\temp 目录内容。而 IE 中则 更进一步，将这些来源分类为本机(my computer)、内网(intranet)、外网(internet)、可信站点(trusted)和不可信站点(untrusted)。 　　如果说 Principal-based 的安全模型中，关键因素是：我是谁(当前帐号)、我要访问什么(目标资源)、我要怎么访问(操作类型)；则在 基于位置的安全模型中变成了：我来自哪里(代码来源)、我要访问什么(目标资源)、我要怎么访问(操作类型)。关键因素虽然只有一个我是谁 到我来自哪里的转变，但其控制粒度能够大大提升。 　　但是这样的基于位置的安全模型还是存在其问题，因为组件之间的可信程度是不同的。例如一个本机控件因为来源于本机，受到系统的信 任，被赋予很高的权限。同时一个恶意代码来源于不受信任的位置，无法执行某项操作。如果权限限定完整的话，本来不会出现问题，但因为 某些权限依赖关系的管理混乱，造成恶意代码可以通过受信任代码执行本不应允许他执行的功能。这也是众多 IE 相关漏洞的问题根本所在， 其受到 IE 现有安全模型的单级信任机制的限制，注定无法彻底解决。 　　要彻底解决此类问题，归根结底必须建立一个可信链验证机制，也就是说执行某个操作的时候，必须检查此操作所有的上级操作组件是否 拥有安全权限，而不仅仅只检测最后一级的组件。这一思路正是 CLR 中代码访问安全检测的设计思路，其关键因素增加了一个：调用我的人都 有哪些，他们是否有相应权限的检测。 　　例如我在建立一个文件的时候，可以强制性检测调用链上的所有组件是否都拥有操作此文件的权限： 以下内容为程序代码: public void CreateFile() { // Create a new FileIO permission object FileIOPermission perm = new FileIOPermission(FileIOPermissionAccess.Write, @C:\SomeFile.txt); try { // Demand the FileIOPermission perm.Demand( ); } catch (SecurityException se) { // Callers do not have necessary permission } // Method implementation... } 　　FileIOPermission 类描述了我需要检测的权限，对 C:\SomeFile.txt 文件可写；FileIOPermission.Demand() 则执行这一权限的检测工 作，遍历此方法调用链上的所有组件，检测他们是否有次权限。这样一来就可以从理论上避免恶意代码通过调用可信组件执行越权操作的问题 。具体的权限定义和使用方法，这里就不详细介绍了。下面就这种检测如何实现做一个结构上的简要分析。 System.Security.CodeAccessPermission System.Security.Permissions.EnvironmentPermission System.Security.Permissions.FileDialogPermission