如何将.net程序集标记为安全？

Question

如何将组装标记为“安全”？

或者，当程序集中的某些内容不“安全”时，如何让Visual告诉我？

有时，除非程序集是“安全的”(例如来自SQL Server)，否则不能使用它。

我希望我的集会被标记为安全。如果我的程序集由于不安全而不能标记为安全，我想知道如何才能知道我的程序集不安全。

Visual中的一些概念似乎与安全性有关，这些概念可能与程序集“安全”有关，也可能与“安全”无关：

1. 允许不安全代码程序集选项：

- What is allowed if i check the _allow unsafe code_ option?
- What is not allowed if i uncheck the _allow unsafe code_ option?
- What relation, if any, does "unsafe code" have to do with an assembly being "safe"?

(我之所以问是因为我的程序集不允许不安全的代码，而是允许P/Invoke调用--我认为这是“不安全”的定义)

​

1. ClsCompliant组装选项： 程序集:CLSCompliant(真)命名空间MyApplication

- What is the relation, if any, does "cls compliant" code have to do with an assembly being "safe"?

​

1. 不安全代码块： int错误；不安全{ error = 0x80004005；} unsafe块内的代码“不安全”
2. UnsafeNativeMathods Microsoft建议创建一个名为UnsafeNativeMethods的类，该类包含不安全的托管代码： SuppressUnmanagedCodeSecurity内部静态类UnsafeNativeMethods {.} 这与SafeNativeMethodsSuppressUnmanagedCodeSecurity内部静态类SafeNativeMethods {.}形成了对比。 它包含安全的本机方法和NativeMethods： 内部静态类SafeNativeMethods {.} 包含本机方法的。

如何将组装标记为“安全”？

SQL如何知道程序集“不安全”？

Answer 1

• 从这中读取Server的“安全”是：

安全权限集是限制最大的权限集。由具有安全权限的程序集执行的代码不能访问外部系统资源，如文件、网络、环境变量或注册表。

所以关于SQL Server代码域中的代码执行权限设置

• VS的Unsafe标志基本上与代码执行安全性无关，但支持非托管代码执行。所以这是关于非托管代码集成到托管代码库中的。
• 定义的CLS Compilant属性是定义使用该属性标记的程序集的代码，就像遵循CSL (公共语言规范)准则的代码一样。这与编译和代码体系结构有关。

如何将组装标记为“安全”？

它在本答案的第一个链接中定义，并与Server集成有关系。

SQL如何知道程序集“不安全”？

考虑到提供的说明：“创建包含类元数据和托管代码作为Server实例中的对象的托管应用程序模块”，Server在metadata上中继，在某些字段中提供关于它是否“安全”的信息。

Answer 2

如何将组装标记为“安全”？

你想错了。

一个你认为可能想杀了你的人递给你一瓶，说“喝这个”。你说“喝酒安全吗？”那家伙说“读瓶子”。你知道的。上面写着“安全饮用”。

你喝吗？

液体是否安全饮用与瓶子上的标签上写着什么无关！把汽油放在一个标有“安全饮用”的瓶子里是完全可能的。

你是把装满可疑液体的瓶子分发给SQL server的人，Server说：“我不相信你要在这个程序集上贴上任何标签。”相反，它将通过限制程序集可以执行的操作来使程序集“安全”。它锁定了该程序集上的权限，以便您的程序集利用SQL服务器的任何尝试都将导致通过异常终止它。

我怎么知道什么时候在我的集会是不安全的？

试着以低信任的方式运行它。它是否在安全异常的情况下坠毁和死亡？如果答案是肯定的，那么根据信任级别，这是不安全的。不同的信任级别授予不同级别的权限。在您自己的计算机上安装的代码通常是完全可信的，从您的公司网络运行的代码不那么受信任，从互联网运行的代码几乎不受信任。在SQL server中运行的代码获得的信任级别最低；它认为几乎所有东西都是不安全的。

如果我检查“允许不安全代码”选项，允许什么？

然后，您可以编写代码，以其选择的方式直接操作指向内存的原始指针。这需要完全信任；如果希望使用不安全代码，则必须不对程序集设置任何限制。不安全的代码可以改变进程中的每一点用户模式内存。

"cls兼容“代码与程序集是否”安全“有什么关系？

除了CLS兼容的代码不允许采用原始指针类型的API之外，没有任何其他。

CLS是公共语言子集--所有兼容的.NET语言中所需的一组特性。这样，您就不必问自己：“嘿，如果我编写了这个以int表示并在C#中返回字符串的方法，我可以从F#调用它吗？”如果您限制自己遵循CLS的规则，那么您就知道任何CLS语言都可以使用您的库，并且您可以使用符合CLS的库，不管它们是用什么语言编写的。这与安全毫无关系。

不安全块中的代码是“不安全的”。

如果写得不好，不安全块中的代码可能会在整个进程中任意损坏内存。我们让您将代码标记为“不安全”，以便您知道在哪里集中您的代码评审工作。在不安全的块中，您负责确保类型和内存安全，而不是C#语言。

一个你没有问的问题：

将程序集标记为“部分受信任调用方的安全”意味着什么？

这是一种将程序集标记为“安全”的情况。通过使用AllowPartiallyTrustedCallerAttribute (APTCA)标记程序集，程序集的作者您断言，如果程序集中的代码是由试图攻击用户的低信任敌对代码调用的，那么程序集中就没有任何低信任敌对代码可以针对用户使用。简而言之，您是在说“即使用户完全信任我的代码，我的代码也不是邪恶代码可以用来对付用户的武器”。

我们发明APTCA的原因是，早在那时，Peter和我发现有一种方法可以让低信任度的呼叫者欺骗JScript.NET代码--默认情况下这是高度信任的--以这样一种方式，低信任的代码可以使JScript.NET代码代表它攻击用户。(这通常被称为“引诱攻击”，因为低信任代码“诱使”高信任代码为其做肮脏的工作。)

作为确保这种错误不再发生的巨大努力的一小部分，CLR团队引入了APTCA。通过将APTCA放在程序集上，您是在告诉您的用户，您正在声明他们对您的工作的信任不会被恶意第三方代码所滥用。不要将APTCA放在程序集上，除非(1)您打算由用户认为可能有敌意的代码调用该程序集，以及(2)您实际上已经完成了彻底的安全检查。

幸运的是，新的基于透明度的安全模型省去了APTCA的大部分需求。

如果程序集中不存在APTCA，则“链接要求”将确保调用程序集的代码完全可信。请注意，这是一个链接需求，而不是一个完整的需求。

Answer 3

在本例中，SQL正在查找已包装在“不安全”块中的代码。下面是指向不安全关键字的MSDN指针

http://msdn.microsoft.com/en-us/library/chfa2zb8.aspx