CLR全面透彻解析 - 将APTCA程序集迁移到.NET Framework 4

CLR全面透彻解析 - 将APTCA程序集迁移到.NET Framework 42011-08-07 MSDN Mike Rousos在 Microsoft .NET Framework 4 中，公共语言运行时（CLR）安全模型发生了不少变化。其中一项变化，即采用 Level2 透明性（与 Silverlight 的安全模型非常相似）很可能影响 AllowPartiallyTrustedCallers （APTCA）库的作者。

该影响源于 APTCA 的基础工作在 CLR v4 中发生了变化。APTCA 属性保持了向部分受信任调用方提供完全可信任库的功能，但具体的提供方式发生了变化，因此，有可能需要对 APTCA 库代码进行一些修改。

注意：本篇文章中的v2 是指 CLR v2，它包括从 .NET Framework versions 2.0 到 3.5 SP1 的所有版本。

V4 之前的APTCA

在 v4 之前，通过对所有入口点的完全信任隐式链接要求，所有签名程序集都受到保护，不提供给部分受信任调用方。这意味着，任何部分受信任代码在尝试访问强名称的程序集时都因为安全性异常而失败。这会阻止部分受信任调用方恶意调用（存在潜在风险的）完全受信任代码。

将 AllowPartiallyTrustedCallers 属性添加到签名的完全受信任库后，可对这些库移除这些隐式链接要求，从而可供部分受信任方使用。因此，APTCA 库通过 APTCA 公开的方法允许部分受信任代码以受控的方式访问特权操作。APTCA 作者有责任确保通过这种方式只向部分受信任方公开安全操作，任何存在潜在风险的操作都应通过隐式链接要求或完整要求加以保护。

V4 中的APTCA

AllowPartiallyTrustedCallers 属性已发生变化。v4 再不用考虑链接要求。事实上，曾在 v2 中存在的对签名库的隐式链接要求已不复存在。而 v4 中所有完全受信任程序集在默认情况下都属于 SecurityCritical。另一方面，v4 中所有部分受信任程序集在默认情况下均属于 SecurityTransparent 。正如下一部分的透明性概述中所言，SecurityTransparent 代码将无法调用 SecurityCritical 代码。

因此，新 v4 透明性系统对完全受信任代码提供与旧的链接要求相同的保护；由于 SecurityCritical 和 SecurityTransparent 是自动应用的透明性级别，部分受信任代码默认情况下无法调用完全受信任的库。

您可能猜到，v4 中对 AllowPartiallyTrustedCallers 的更改与此有关。在 v4 中，APTCA 的变化是从应用 SecurityCritical 的程序集取消了自动 SecurityCritical 行为。因此程序集默认为 SecurityTransparent，但允许 APTCA 程序集作者在必要时对特定类型和方法应用更加具体的 SecurityCritical 和 SecuritySafeCritical 属性。

透明性速成教程

熟悉 Silverlight 安全模型的读者对于 SecurityTransparent 和 SecurityCritical 等透明性属性的作用并不会感到陌生，因为新 v4 透明性模型与 Silverlight 安全模型非常相似。

让我们先来了解一下三个主要的透明性属性：SecurityTransparent、SecuritySafeCritical 和 SecurityCritical。

SecurityTransparent：标记为 SecurityTransparent 的代码从安全性角度而言是可靠的。它不能完成任何危险操作，例如声明权限、执行无法验证的代码或调用本机代码。它也不能直接调用 SecurityCritical 代码。

如上文所述，出于安全的考虑，所有部分受信任代码都强制为 SecurityTransparent。这也是 APTCA 库的默认透明性。

SecurityCritical：与 SecurityTransparent 不同，SecurityCritical 代码能够执行任何所需操作。它能够执行声明、调用本机代码和其他操作。它能够调用其他方法，且不受透明性标记的限制。

只有完全受信任代码才能为 SecurityCritical。事实上，（非 APTCA）完全受信任代码默认情况下属于 SecurityCritical，从而保护其免受透明的部分受信任调用方的调用。

SecuritySafeCritical：SecuritySafeCritical 代码起着桥梁的作用，它允许透明代码调用关键方法。SecuritySafeCritical 代码与 SecurityCritical 代码的权限相同，但它可由 SecurityTransparent 代码调用。因此，SecuritySafeCritical 代码必须以安全方式公开基础 SecurityCritical 方法（以避免一些部分受信任的恶意代码尝试通过 SecuritySafeCritical 层攻击这些方法），这一点极为重要。

与 SecurityCritical 代码一样，SecuritySafeCritical 代码必须完全受信任。