14

另请参阅“代码访问安全性”是否适用于任何现实世界？

我想得到一些关于这个的其他意见...

我喜欢桌面应用程序的代码访问安全的想法。但在 .NET 的生命周期中，我不得不承认，我实际上从未遇到过 CAS 确实阻止了对我有利的东西的情况。

然而，我曾多次遇到像跨映射驱动器共享快速 .NET 应用程序这样简单的事情成为企业代码访问的噩梦。不得不打破 caspol.exe 来创建受信任的路径规则，并且无法清楚地知道失败的原因，这使得 CAS 似乎给开发和部署过程带来了比它在安全方面提供的更多的挫败感。

我想听听 CAS 实际上帮助多于伤害的某些情况，或者是否还有其他人对其当前的实施和默认设置感到沮丧。

4

4 回答 4

7

他们自己的 .NET 团队得出了相同的结论，即正在为 .NET#4 重新设计程序集访问安全性。查看此博客以获取更多信息： .NET 安全博客

于 2009-06-26T05:39:38.373 回答
4

这儿这儿！我分享了许多相同的挫败感。当然，过于复杂和可怕的文档基本上鼓励开发人员绕过它或使用过于宽泛的规则。对任何人来说，安全永远都是一个难题，但 CAS 确实很难做到正确。

于 2009-06-26T04:04:01.810 回答
1

我不得不处理 CAS，但这并不太难，因为我只需要在十几个工作站上部署它。您还可以通过组策略推出所需的设置。

但是要回答你的问题，不，我认为它没有帮助。

不过，从好的方面来看，从 .NET 3.5 开始，您可以在没有 CAS 的情况下跨网络共享运行应用程序。

于 2009-06-26T04:12:23.153 回答
0

经过大量搜索后，我偶然发现了 CLR 团队的这篇博客文章，它不仅证实了 CAS 将在 .NET 4 中消失，而且还提供了一个很好的指南，说明什么会破坏以及如何迁移到新的沙盒模型：新安全模型: 转向更好的沙盒。来自文章：

在 v4 之前的 .Net Framework 版本中，我们有很多方法来限制程序集的权限，甚至是程序集中的某些代码路径：

  1. Stack-walk 修饰符：Deny、PermitOnly

  2. 程序集级请求：RequestOptional、RequestRefuse、RequestMinimum

  3. 策略更改：caspol 和 AppDomain.SetPolicyLevel

  4. Loading an assembly with a Zone other than MyComputer

In the past, these APIs have been a source of confusion for host and application writers. In .Net Framework 4, these methods of restricting permissions are marked obsolete and we hope to remove them at a point in the future.

Most distressing is the fact that all these deprecated methods of creating a sandbox will start throwing a NotSupportedException. This is exceptionally precarious for any poor souls (like myself) that for whatever reason are required to implement CAS in their organization at this time. You have been warned.

于 2010-03-23T16:00:19.630 回答