.NET 4、AllowPartiallyTrustedCallers属性和SecurityCritical等安全标记

Question

我是新来的C#，正在尝试理解new security features of .NET-4。

为了填写一些细节，我目前正在尝试更新AutofacContrib.Moq以使用最新的Moq。我在.NET-3.5及更低版本上这样做没有任何问题。但在.NET-4中，安全限制会导致大量的安全异常。

Moq有一个用SecurityCritical属性标记的方法GetObjectData。AutofacContrib.Moq设置了AllowPartiallyTrustedCallers属性，这是异常的根源。似乎与其添加SecurityLevel为1的SecurityRules属性，不如删除AllowPartiallyTrustedCallers属性。我相信这使得程序集在默认情况下是SecurityTransparent的，这可能还不够(尽管AutofacContrib.Moq单元测试通过了)。

我现在的主要问题是，面向.NET-4的程序集是否应该使用AllowPartiallyTrustedCallers属性？但是，考虑到我还没有完全理解所有内容，在处理带有安全标记的程序集时应该考虑哪些细节？我是否需要在程序集直接或间接使用标记为SecurityCritical的内容时，显式地使用安全属性对其进行标记

Answer 1

您是对的:在.NET 4中，将APTCA留在那里会生成程序集SecurityTransparent，这可能是导致您痛苦的原因。

MSDN文章Migrating an APTCA Assembly to the .NET Framework 4对.NET 4中AllowPartiallyTrustedCallersAttribute的更改进行了很好的讨论和解释。

具体地说：

AllowPartiallyTrustedCallers属性已更改。在v4中，它不再与链接要求有任何关系。事实上，v2中签名库上的隐式链接要求已经消失了。相反，默认情况下，v4中所有完全受信任的程序集都是SecurityCritical。

snip /

在v4中，APTCA的作用是从应用它的程序集中删除自动SecurityCritical行为。

还有..。

因为AllowPartiallyTrustedCallers属性导致整个程序集在默认情况下为SecurityTransparent，所以程序集的作者必须明确地将需要执行特权操作的方法标记为SecurityCritical或SecuritySafeCritical。

(这真的是一篇很好的文章，作者Mike Rousos写得很好。I encourage you to read it in its entirety.)

如果您要开始一个新的.NET 4库，最好坚持使用.NET 4安全模型，并在需要的地方使用适当的SecurityCritical、SecuritySafeCritical和SecurityTransparent属性。它们比旧的代码访问安全性更容易管理和理解。

如果你正在将一个旧的库迁移到新的模型，在文章中有一个很好的例子来说明如何做到这一点……但从根本上说，这相当于移除旧的LinkDemands，并在其位置上添加SecurityCritical。

在您的特定情况下，最快的方法是添加SecurityRules属性，这样您就可以获得旧的行为，但我不确定我是否认为这是正确的方法。正确的方法可能是去掉APTCA并在程序集because the assembly may contain SecurityCritical code上添加SecurityCritical，然后用SecuritySafeCritical标记调用SecurityCritical代码的各种类型(例如，引用GetObjectData的内容)，这样SecurityTransparent代码就可以调用它。当然，第二种方法需要更多的工作，因此您可能希望运行SecAnnotate.exe并获取一些自动提示。

查看Moq主干，搜索GetObjectData会发现这个方法是异常序列化机制(System.Exception上的ISerializable.GetObjectData)的重写，无论如何只有SecurityCritical代码才会调用它，所以如果您只是丢失APTCA并将程序集标记为SecurityCritical，您甚至可能不会遇到任何麻烦。

There is an issue filed on Autofac to update it to the latest security model.如果你喜欢这个想法，去投票/评论它。

抱歉，这不是一个简短的回答。不幸的是，安全性从来都不容易。:S