策略
证据本身相对没多大用处，其真正的用途在于充当安全策略的输入。CLR使用安全策略，并且基于程序集的证据决定为给定的程序集赋予什么权限。系统管理员和用户可以配置CLR安全策略。CLR的安全策略也是可扩展的，它允许你将自定义策略算法插入到现存的基础结构中。
你可以指定多达四种级别的安全策略，这些策略可以通过System.Security．PclicyLevelType枚举表示：
namespace System.Security{
publie enurn PolicyLevelType{
User,
Machine,
Enterprise,
AppDomain
}
}
User策略级别专门针对用户个体，而Machine策略级别则适明于特定宿主机器上的所有用户，Enterorise策略级别适用于同一活动目录中的所有计算机。而AppDomain策略级别特别针对运行在操作系统进程内部的特定应用程序。
在这四种策略级别当中，除了AppDomain策略级别外，其他的都是从基于XML的配置文件自动加载的。这些文件是以原始XML的形式使用caspol.exp工具或者MMC（管理控制台）插件macorcfg.msc进行编辑的。Machine和EnterpriSe级别分别是从文件security.config和enterprisesec.config中读出的。这些文件驻留在CLR版本相关的安装目录下的Config子目录下。User策略级别是从
Application Data\Microsoft\CLR Securtiy Config\v1.O.nnnn\security.config文件中读出的，这个文件可在用户相关文件目录中找到。AppDomain策略必须通过编程的方式调用System.AppDomain.setAppDomainPolicy方法指定。
四种策略级别的联合体被称为系统策略层次结构(policy hierarchy)。层次结构中的每个级别提供了一套基于现存证据的权限。准备授予的结果权限集台是这四种策略级别中的每一个级别所授予的权限的交集（不是并集），如图9.l所示。
策略层次结构使用交集而不是并集，因为CLR的安全模型是基于授予(grant)特权而不是禁止(deny)特权的机制。对于熟悉WindowsNT安全性的读者．这个模型与Win32特权或COM+角色的概念相似—那就是，禁止访问的惟一方法是不给它授于合适的权限．不像Win32动态访问控制列表( DACL)，这个模型没有办法显式地拒绝受保护的操作或资源的访问。为此，默认的Enterprise、User和AppDomain策略级别对于当前的证据都授予了完全信任权限：而默认的Machine策略级别，仅对于从MyComputer安全区域或具有Microsoft或ECMA公钥加载而来的的代码，授于完全信任的权限。对于不是从Microsoft和ECMA来的代码（即从其他安全区域加载的），Machine策略将授予极低的权限。
像证据一样，策略层次结构是由安全基础结构隐式地使用的，但也能够以可编程的方式访问。CLR通过System.Security.Policy.PolicyLevel类型在层次结构中公开了每个级别，并且由System.Security.SecurityManager.PolicyHierarchy方法公开了策略级别的集合。下面的代码使用这个方法枚举了由当前程序所使用的策略级别，并且显示了用于加载策略的文件名：
using System;
using Sysetm.Collections;
using System.Security;
using System.Security.Policy;
class App{
static void Main(){
Ienumerator i=SecurityManager.PolicyHierarchy();
while(i.MoveNext()){
PolicyLevel level=(PolicyLevel)i.Current;
Console.WriteLine(“{0,10}:{1}”,level.Label,level.StoreLocation);
}
}
}
在作者的机器上，这个程序显示如下：
注意，默认情形下没有与AppDomain相关的策略。
每个策略级别由三个组件组成；一个策略级别包含一个命名的权限集(Permission set)列表（通过PolicyLevel.NamedPermissionSets属性可见）．它们中的每一个都被授予零个或多个特权；一个策略级别还包含一个代码组（code group）层次结构(通过PolicyLevel.R00tCodeGroup属性可见),用于根据给定的证据体决定授予哪些权限集；最后一个策略级别还包含了一个完全信任程序集列表(full-trust assembly)(通过PolicyLevel.FullTrusthAssemblies属性可见）。它显式地列出了需要实施安全策略的类型的程序集。例如，如果定义了一个自定义权限类型，它的程序集必须出现在这个别表中，以便安全策略可以识别它。由于扩展安全策略已经超出了本书的范围，我们将重点探讨代码组和命名权限集。
代码组用于根据证据授予权限，为此，一个代码组拥有两个主要属性：成员条件和权限集名字。如图9.2所示，成员条件(membership condition）使用提供的证据决定一个可疑程序集是否是这个代码组的成员。假如成员条件认为证据满足条件，策略就会把包含在命名权限集中的权限授予这个程序集。
成员条件是强类型的，由实现了System.Security.Policy.ImembershipCondition接口的CLR类型所提供。这个接口有一个令人感兴趣的方法Check:
namespace System.Security.Policy{
public
interface ImembershipCondition{
bool Check(Evidence evidence);
//为了清晰起见，其余部分省略
}
}
对于一个给定的任意策略级别，下面的方法决定一个给定的程序集是否为根代码组的成员。
static bool IsInRootGroup(Assembly assm,PolicyLevel level){
//获取程序集的证据
Evidence evidence=assm.Evidence;
//获取根代码组的证据
CodeGroup group=level.RootCodeGroup;
ImembershipCondition cond=group.MembershipCondition;
//成员检查
return cond.Check(evidence);
}
因为对于所有内置类型来说，根代码组匹配所有程序集，所以这个方法总是返回true。p