CAS 因其复杂性而常常为人诟病。开发人员在误用了代码块的属性时很少，甚至几乎无法获得任何反馈。对于管理员来说情况就更糟糕了。对于每个批准的 CAS 策略都需要手动设置，但是应用程序很少把他们所需的许可列出来。更糟糕的是，对于.NET 的各个版本都必须重新创建 CAS 策略。
实践中，CAS 更关注安全威胁而非安全本身。默认情况下，执行文件共享的许可与把文件从文件共享复制到本地磁盘的许可不同。如果该执行操作未被授权，那么 CAS 是根本不会放行的。
在.NET 4.0 版本中，全局 CAS 策略默认情况下会被停用。系统管理员则被鼓励使用更有效的方式来进行替代，例如：Windows 软件限制策略。如果确实需要 CAS，就可以在每个应用程序的 app.config 文件中，将 runtime/NetFx40_LegacySecurityPolicyenabled 设置为 true 即可。
一般情况下，代码默认都在完全信任的的环境下运行。许可在应用程序域级别获取，而不是在单个应用程序域中混合安全级别的策略。使用 URL 调用 Assembly.LoadFrom 则表示该程序集完全可信。
当托管代码被寄存的时候，它会运行于宿主所指定许可的沙盒中，例如在 SQLCLR 中运行托管程序集，或者利用 ClickOnce 运行从网络中安装的应用程序。在受到沙盒保护的应用程序域中，每个程序集会以部分或完全可信的形式运行，而不需要遵循原有复杂系统中遍历堆栈和链接的要求。
在新的模型中，在创建应用程序域的时候，必须明确指定部分可信的程序集列表，同时也必须包含一个完整可信的程序集列表。
实际上，代码可以分为三个级别。最高级别，即“Critical”，是完全可信的代码，它可以执行任何操作。最低级别的代码，“Transparent”，不能直接调用 Critical 级别的代码。标识为“Safe Critical”的代码在两者间起到桥梁的作用。我们很容易理解“Transparent”和“Critical”级别的代码，“Transparent”代码由沙盒重点监控，“Critical”代码则完全不受约束。我们需要关注的代码就是“Safe Critical”代码，它们非常少，需要仔细的进行检查。它更像内核与用户之间的通道代码，即使“Safe Critical”代码的一个错误也会产生灾难性后果。
如果这些看起来都似曾相识也很正常。这种二级安全透明（Level 2 Security Transparency）模型已经在 Silverlight 平台中证实可行。您可以在 MSDN 中找到更多关于二级安全透明的资料。
查看英文原文： Microsoft is Dropping Code Access Security in .NET 4.0
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论