代码访问安全性 - 了解为什么 SecurityTransparent 可以调用 SecurityCritical

本文关键字:调用 SecurityCritical SecurityTransparent 为什么 访问 安全性 了解 代码 | 更新日期: 2023-09-27 18:33:56

我正在研究代码访问安全性。这需要一些努力来理解,所以我想我最终会使用 Reflector 并开始研究 .NET 4.0 如何使用安全属性。

观察

System.IO.File.Delete 方法使用 [SecuritySafeCritical] 属性进行修饰。

System.IO.File.Delete方法委托给内部方法 InternalDelete,该方法使用 [SecurityCritical] 属性进行修饰。

我的一个MVC应用程序类中有一个名为DeleteFile的方法,它以SecurityTransparent运行(我已经通过检查DeleteFile的MethodInfo.IsSecurityCritical属性进行了验证(

权限

根据我目前的理解,这意味着:

  1. System.IO.File.Delete 可以调用 InternalDelete,因为[SecuritySafeCritical]方法都可以调用 [SecurityCritical]因此不会引发 SecurityException。
  2. DeleteFile 可以调用 System.IO.File.Delete,因为[SecurityTransparent]可以调用[SecuritySafeCritical]

所以基本上,在不调整任何开箱即用的安全设置的情况下,此代码将成功删除一个名为 test 的虚拟文件.txt

namespace MyTestMvcApp
{
    public class FileHelpers()
    {
        // Has SecurityTransparent
        public void DeleteFile()
        {
            // Will succesfully delete the file
            File.Delete("test.txt");
        }
    }
}

混乱

System.IO.File.DeleteInternalDelete 方法中,它使用 CodeAccessPermission.Demand 方法来检查堆栈中的所有调用方是否具有必要的权限。我不太明白的是 MSDN 文档中的这一行 CodeAccessPermission.Demand

不检查调用此方法的代码的权限;检查从该代码的直接调用方开始,然后沿堆栈向上进行。

所以我的问题是,如果我的应用程序的 DeleteFile 方法是SecurityTransparent,为什么允许调用 SecurityCritical 方法?

这可能是一个破碎的例子,也许缺少一些概念,但正如我所说,我仍然在思考它,人们可以提供的任何见解,我就会更多地发展我的理解。

谢谢

代码访问安全性 - 了解为什么 SecurityTransparent 可以调用 SecurityCritical

您混淆了两种 CAS 强制机制。 虽然它们确实有一点互动,但这与您似乎担心的方式并不完全相同。 出于完全许可要求的目的,如 Demand 所代表的那样,它们本质上是独立的。

CLR 在执行代码之前应用透明度验证。 如果通过,CLR 将验证通过属性应用的任何声明性 CAS 要求。 如果这些通过(或不存在(,则 CLR 将执行代码,此时命令性(内联(需求将运行。

Demand 文档关于"不检查调用此方法的代码的权限"的说明适用于 Demand 方法本身。 换句话说,如果你有一个调用 Foo 的方法 Foo,则经过验证的调用堆栈启动将调用 Foo 的调用方,而不是 Foo 本身。 例如,如果您有调用链A -> B -> C -> Foo -> Demand,则只会验证 A、B 和 C 以检查它们是否具有授予的权限。