Security Briefs...小心完全信任的代码

核心提示： 想想看，这意味着什么？你发布了一个程序集，Security Briefs...小心完全信任的代码(3)，其中包含只能在内部使用的敏感的私有方法，那么用什么来阻止客户端直接调用这些私有方法，虽然前者将它在整个机器上关闭，而后者只在单进程中有效——尽管不能保证它会稳定地

想想看，这意味着什么？你发布了一个程序集，其中包含只能在内部使用的敏感的私有方法。那么用什么来阻止客户端直接调用这些私有方法， 多半是传递可能导致你的方法出现故障和危险行为的畸形输入？。这种情况下毫无办法，因为你没有控制客户端的安全策略。但是等等，也许你听说过 一种叫强名称 LinkDemand (strong name LinkDemand)的特性，Framework Class Library（FCL）使用它，这样看来还不错。看看下面的程序：

public class NuclearReactor {
　　[StrongNameIdentityPermission(
　　SecurityAction.LinkDemand,
　　PublicKey="002400000...")]
　　private void Meltdown() {
　　　　// calling assembly must have specified public key!
　　}
}

现在前面使用反射的诀窍行不通了，没有人能调用 Meltdown 方法，除非调用程序集具备专门的公共密钥。链接需要（Link demand）命令 CLR 检查在 JIT 编译时链接到该方法的程序集，以保证它能满足链接需要。通过使用 StrongNameIdentityPermission，我要求调用者必须具备一个特殊的公共密钥。

不幸的是，完全信任代码也能以不止一种方法避开这个许可需求。最简单的方法是用下面的命令行选项完全关闭代码存取安全（CAS）。

caspol -s off

幸好，你必须是管理员才能运行这条命令（即使你是管理员，也决不要这么做！）。实际上，这么一条命令很难找到存在的理由，Whidbey 团队正在考虑 将它从下一个版本中删除掉。然而，如果应用程序具备高级别信度，即使非管理员也能编写如下代码来做同样的事情：

using System.Security;
class EvilCodeWithFullTrust {
static void Main() {
　　SecurityManager.SecurityEnabled = false;
　　// now call Meltdown via reflection!
　　}
}

这些用于关闭 CAS 的机制效果相同，虽然前者将它在整个机器上关闭，而后者只在单进程中有效——尽管不能保证它会稳定地工作。更多细节请参见相关文档。