接触CAS(三)

Author ： 水如烟 

 

学习CAS（代码安全访问性），真的不简单， 直想放弃。

CAS是CLR（公共语言运行库）的基础，贯穿于CLR的全部。要学习掌握它，必须对CLR有个总体的把握，由此才能理解，才能找到主线。

并且，它实在不是简单的代码安全，它服从Window的安全机制。它是综合的，也是基本的。在它面前，自己没信心来认知它。

 

可以从SQL Server着眼，看它是如何实现CAS的。

这部分文档来自MSND中关于SQL Server CLR集成简介。 贴出来。

 

Microsoft SQL Server 与 Microsoft .NET Framework 公共语言运行库 (CLR) 相集成，这种安全模型可管理和保护 SQL Server 中运行的不同类型 CLR 和非 CLR 对象之间的访问。这些对象可以通过 Transact-SQL 语句或服务器中运行的其他 CLR 对象进行调用。

CLR 集成代码访问安全性

CLR 支持一种用于托管代码的安全模型，称为代码访问安全性 (CAS)。在此模型中，基于代码的标识（而不是运行代码的用户或进程的标识）为程序集授予权限。基于证据和策略授予 CAS 权限。例如，程序集的来源是一种证据，策略可以指定应为从 Internet 下载的代码授予一组非常有限的权限。系统管理员设置策略，撤消用户和开发人员的安全决策。确定为程序集授予的权限的安全策略在三个不同的位置定义：

·                 计算机策略 ：此策略应用于安装 SQL Server 的计算机中运行的所有托管代码。

·                 用户策略 ：此策略应用于由进程托管的托管代码。对于 SQL Server，用户策略针对运行 SQL Server 服务所使用的 Windows 帐户。

·                 主机策略 ：此策略由 CLR 主机（在此例中为 SQL Server）设置，应用于该主机中运行的托管代码。

为在 SQL Server 内部运行的托管代码授予的 CAS 权限集是上述三个策略级别授予的权限集的交集。即使 SQL Server 为 SQL Server 中加载的程序集授予了权限集，最终为用户代码授予的权限集仍可能会受到用户级和计算机级策略的进一步限制。

CLR CAS 假定运行库可以托管完全可信的代码和部分可信的代码。受 CLR CAS 保护的资源通常由托管应用程序编程接口 (API) 包装，需要具有相应的权限才允许访问资源。仅当调用堆栈中的所有调用方（在程序集级别）均具有相应的资源权限时，才能满足对权限的要求。

SQL Server 主机策略级权限集

SQL Server 主机策略级别为用户定义的程序集授予的 CAS 权限集由创建程序集时指定的权限集确定。有三个权限集：SAFE、EXTERNAL_ACCESS 和 UNSAFE。

SQL Server 在托管 CLR 时为其提供主机级的安全策略级别；此策略是始终生效的两个策略级别下面的另外一个策略级别。SQL Server 创建的每个应用程序域均设置此策略。此策略并非针对在 SQL Server 创建 CLR 实例时将生效的默认应用程序域。

SQL Server 主机级策略是系统程序集的 SQL Server 固定策略和用户程序集的用户指定策略的组合。CLR 程序集和 SQL Server 系统程序集的固定策略为程序集授予完全信任的权限。SQL Server 主机策略的用户指定部分基于为每个程序集指定三个权限集之一的程序集所有者：

·                 SAFE ：只允许内部计算和本地数据访问。SAFE 是限制性最强的权限集。通过具有 SAFE 权限的程序集执行的代码无法访问外部系统资源，例如文件、网络、环境变量或注册表。

·                 EXTERNAL_ACCESS ：与 SAFE 权限集类似，但是可以访问外部系统资源，例如文件、网络、环境变量和注册表。

·                 UNSAFE ：UNSAFE 允许程序集对资源进行不受限制的访问，无论在 SQL Server 内部还是外部。从 UNSAFE 程序集中执行的代码可以调用非托管代码。

安全注意

如果程序集执行计算和数据管理任务，而且不访问 SQL Server 外部的资源，SAFE 是建议的权限设置。如果程序集访问 SQL Server 外部的资源，建议使用 EXTERNAL_ACCESS。默认情况下，EXTERNAL_ACCESS 程序集作为 SQL Server 服务帐户执行。EXTERNAL_ACCESS 代码可能会显式模拟调用方的 Windows 经过身份验证的安全上下文。因为默认设置是作为 SQL Server 服务帐户执行，所以，只应为作为服务帐户运行的可信登录帐户授予执行 EXTERNAL_ACCESS 的权限。出于安全起见，EXTERNAL_ACCESS 和 UNSAFE 程序集相同。但是，EXTERNAL_ACCESS 程序集提供了 UNSAFE 程序集中没有的各种可靠性和性能保护。如果指定 UNSAFE，将允许程序集中的代码对 SQL Server 进程空间执行非法操作，因此可能会影响 SQL Server 的性能和可缩放性。

访问外部资源

如果用户定义类型 (UDT)、存储过程或其他类型的构造程序集使用 SAFE 权限集注册，构造中执行的托管代码将无法访问外部资源。但是，如果指定了 EXTERNAL_ACCESS 或 UNSAFE 权限集，并且托管代码尝试访问外部资源，SQL Server 将应用下列规则：

如果	那么
执行上下文对应于某个 SQL Server 登录帐户。	尝试访问外部资源时被拒绝，并引发安全异常。
执行上下文对应于某个 Windows 登录帐户，并且执行上下文是原始调用方。	外部资源在 SQL Server 服务帐户的安全上下文下访问。
调用方不是原始调用方。	访问被拒绝，并引发安全异常。

通过链接调用代码

SQL Server CLR 集成安全模型旨在控制在 SQL Server 内部执行的代码，并避免通过托管代码对受保护的系统资源进行特权升级攻击。用户定义的代码可以使用 Transact-SQL 或一种托管语言在 SQL Server 内部调用其他代码。这些对象之间的关系称为链接。下表介绍了三种链接类型。

链接类型	说明
调用	对应于代码调用，从调用对象（例如调用存储过程的 Transact-SQL 批处理）或 CLR 存储过程或函数的用户。
表访问	对应于在表、视图或表值函数中检索或修改值。与调用链接类似，只是在 SELECT、INSERT、UPDATE 和 DELETE 权限方面的访问控制更加细化。
两个对象之间的选通	关系建立后，就不再检查该关系的权限。

SQL Server CLR 代码安全检查

SQL Server 中的代码始终在进程上下文或者用户帐户或角色下执行，权限授予该帐户或角色。调用 CLR 代码之后，SQL Server 将执行下列安全检查：

·                 所有调用均要求具有 EXECUTE 权限，除非调用在相同对象中进行。组件间的调用不要求进行任何权限检查。在执行时检查权限。

·                 选通链接要求在创建调用对象时，对被调用方具有 REFERENCE 权限。在创建对象时，将检查调用对象的所有者的权限。

·                 表访问链接要求对正在访问的表或视图具有相应的 SELECT、INSERT、UPDATE 或 DELETE 权限。

·                 针对当前的执行上下文检查权限。过程和函数可以使用与调用方不同的执行上下文创建。程序集始终使用调用方作为执行上下文创建。

CLR 集成安全性和模拟

在托管代码访问外部资源时，SQL Server 不会自动模拟执行例程所处的当前执行上下文。EXTERNAL_ACCESS 和 UNSAFE 程序集中的代码可以显式模拟当前的执行上下文，如下所示：

进程中数据访问提供程序提供了一个 API ( WindowsIdentity ) ，可以用于检索与当前安全上下文关联的标识。EXTERNAL_ACCESS 和 UNSAFE 程序集中的托管代码可以使用此方法来检索上下文并使用 .NET Framework Impersonate 方法模拟该上下文。用户代码显式模拟时，受到下列限制：

·                 托管代码处于模拟状态时，不允许进行进程中数据访问。代码可以取消模拟状态，然后调用进程中数据访问。注意，要取消模拟，要求存储原始 Impersonate 方法的返回值（一个 WindowsImpersonationContext 对象），并在此 WindowsImpersonationContext 上调用 Undo 方法。

此限制意味着在进行进程中数据访问时，始终在会话生效的当前安全上下文中执行，不能通过托管代码中的显式模拟进行修改。

·                 为了异步执行托管代码（例如，通过异步创建线程和运行代码的 UNSAFE 程序集），从不允许进行进程中数据访问，无论是否存在模拟。

如果代码在不同于 SQL Server 的模拟上下文中运行，则不能执行进程中数据访问调用；在进行进程中数据访问调用之前，应取消模拟上下文。从托管代码进行进程中数据访问时，始终使用托管代码的 Transact-SQL 入口点的原始执行上下文进行授权。

EXTERNAL_ACCESS 程序集和 UNSAFE 程序集均使用 SQL Server 服务帐户访问操作系统资源，除非它们自发地模拟如上上述的当前安全上下文。因此，EXTERNAL_ACCESS 程序集的作者的信任级别需要高于 SAFE 程序集的作者的信任级别，后者通过 EXTERNAL_ACCESS 登录级权限指定。只应为在 SQL Server 服务帐户下运行代码的可信登录帐户授予 EXTERNAL_ACCESS 权限。

CLR 集成安全性和应用程序域

SQL Server 将属于相同所有者的程序集加载到相同的应用程序域中。依靠相同应用程序域中运行的程序集集合，程序集可以在执行时使用 .NET Framework 反映 API 或其他手段相互发现对方，并且可以通过后绑定方式进行调用。因为对属于相同所有者的程序集进行此类调用，所以，不检查这些调用的任何 SQL Server 权限。应用程序域中程序集的位置架构主要为了实现可缩放性、安全性和隔离目标，在以后的版本中可能会更改。因此，不应通过后绑定机制查找相同应用程序中的程序集。