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

核心提示： 所以，当所有代码都被信任时，Security Briefs...小心完全信任的代码(7)，AppDomain 将没有安全性可言，你需要部分信任环境，代号为“Longhorn”，届时即便本地安装的代码都不能以完全信任方式运行，以给予AppDomain 真正的保护屏障，

所以，当所有代码都被信任时，AppDomain 将没有安全性可言。你需要部分信任环境，以给予AppDomain 真正的保护屏障， 部分信任需要验证托管代码并限制对本地代码的存取。默认情况下，ASP.NET 服务器应用程序以完全信任模式运行，因为所有代码都被安装在该服务器上。实际上，1.1 版本之前的 .NET Framework 如果没有完全信任环境，它甚至都不可能运行 ASP.NET 应用程序。现在，我们很容易强制服务器上的 Web 应用以部分信任方式运行，方法是在 machine.config 文件中这样设置：

<configuration>
<system.web>
<trust level=''Medium''/>
</system.web>
</configuration>

坦白地讲，我怀疑你会发现很多 ISPs 这么做，因为很多开发者不知道，也不情愿编写被部分信任的 Web 应用。尽管我希望这种情况得到改变。就现在的状况，如果你决定在共享环境中部署你的 ASP.NET 应用，那么应该问许多有关如何隔离你的 ASP.NET 应用的问题。你应该首选 Windows Server® 2003，而不是 Windows Server 2000，因为后者只支持单工作者进程的 ASP.NET 应用。确认 ISP 给你自己拥有的具备专用 Windows 用户帐号的私有工作者进程。有些运行 Windows 2000 的 ISP 会用虚拟目录将一个 Web 应用与另一个隔离开来。一定要问清楚，以便了解自己的处境。当然，最好是在自己的专用 Web 服务器上部署自己的应用程序。

完全信任代码有任何限制吗?

现在，经过上面的讨论，你可能对完全信任代码印象深刻，它们无所不能。但是记住了，CLR 仍然运行在操作系统最上层，它应该有自己的安全约束。当我说 到完全信任代码，我其实是在说这个代码可以做用户运行它时被允许做的任何事情。举个例子：鲍勃运行了一个安装在它本地机器上的托管应用程序，目前只涉及到 CLR，默认情况下，该应用以完全信任方式运行。但是如果鲍勃登录的 Windows 防止他存取某个特定的文件，托管应用会有相同的约束。CLR 中的信任是按比例增减其上限，所谓完全信任，即达到用户运行运行该应用程序特权级别。象 ASP.NET 这样的服务器应用程序，这个上限是根据所选的服务器进程的安全来考虑的，这也是我选择 Windows Server 2003 的原因，它允许我在单独的进程中运行每一个 ASP.NET 应用，并且每个都具备我想要的任何特权级别。

总结

本文目的是论证 CLR 的许多安全特性只能在部分信任环境被强制。虽然完全信任的概念对某些人似乎显而易见，我回顾了大量设计，这些设计假设 CLR 的安全完全不会用到完全信任的情况。如果你将 CLR 的内建安全与 Windows 的内建安全做个比较，完全信任方式运行类似以SYSTEM身份运行。完全信任代码可以获得 CLR 所有内建的安全特性。这就是为什么它被称为完全信任的原因——它必须被信任去做正确的事情。SYSTEM 可以获得 Windows 中的任何安全约束，这就是为什么以 SYSTEM 身份运行的代码必须被信任的原因。

你面临的挑战是学习编写在部分信任环境中运行的代码。Ivan Medvedev 在 Writing managed code for semi-trusted environment 中有一些好的忠告。如果我在 PDC 上所看到的是暗示的话，那么对于下一个 Windows 版本，代号为“Longhorn”，届时即便本地安装的代码都不能以完全信任方式运行。牢记最少特权原则，设计和编码是都要了然于心！