任何真实世界使用的“代码访问安全性”是什么?

警告:

自从问这个问题以来,.Net和.Net内核的较新版本已经删除和/或更改了“代码访问安全性”(CAS)。

原问题:

我正在为70-536 .NET框架 – 应用程序开发基础考试进行学习 ,因为我一直在编程.NET多年,这不应该很难!

然而,我不得不学习“代码访问安全性”(CAS),因为我从来没有需要使用或configuration它,我想知道是否有其他人已经发现它的真实生活中的用法?

请提供您何时使用CAS的例子,它是解决scheme的一部分,而不是问题的一部分。

(到目前为止,其他所有东西都与我在.NET编程年代所做的任务有一些关系)


相关问题:

  • 为什么要使用CAS(代码访问安全性)? 除了微软使用它之外,这个例子很less有真实的例子。
  • 任何人真的使用代码访问安全来保护他们的程序集和/或方法?
  • 什么是.NET中的代码访问安全性 – 很好地定义了CAS,但没有给出实例。
  • 。 NET代码访问安全性:有用还是过于复杂?

目前为止的结果。

  • CAS在托pipe第三方代码时非常有用。 例如,一个networking托pipe公司可以使用它来阻止客户的Asp.net代码破坏服务器。 (当.NET用作VBA的替代品时,Office也使用它)

  • 到目前为止,在Microsoft应用程序之外使用的唯一详细示例是:

    我最近做的一个项目有类似的东西:允许用户上传一个库,并testing它的性能(“谁制造最好的algorithm”)。 不用说,我们在那里需要大量的CAS。

  • 中国科学院似乎对获得JITDCauthentication是有用的,就像美国国防部,但是我不知道CAS是否有任何实际价值,或者如果只是盒子滴答作响。

(如果您需要绕过使用CAS的主机,并且您有机器上的pipe理员权限,则可以将您的程序集放入GAC中。)

outlook未来, .net 4中的CAS稍微复杂一些 。


至less它看起来像新的微软考试将不会有包括中科院的“基础”考试。 我不知道它是否会进入新的Winforms / WPF考试。

我常常在“现实世界”中遇到代码访问安全性,通常在我最不期待的时候。 从某种意义上说,如果SilverLight 不是最终select不使用CAS ,那么SilverLight将会是一个很好的现实应用。

托pipe提供商

你看到它的地方是需要安全的环境:当然,ASP.NET本身,但ASP.NET托pipe服务提供商使用修改的安全模型,以防止他们的宝贵系统入侵。 我知道一个事实,Webhost4Life使用这个(没有在他们的网站上的信息,但我已经与他们合作,它在那里,真的)。 进一步看,其他ASP.NET托pipe服务提供商也是这样做的,但是他们并不十分清楚: godaddy.com上的线程不想改变CAS(并且不清楚什么是支持的,哪些不支持),或者在1和1上进行相关的讨论 。 一些云托pipe站点(rackspacecloud)进一步采取了一些行动,并且“与微软合作修改完全信任级别”,无论这可能是什么。

简而言之:如果你find一个ASP.NET主机,很可能他们使用CAS来阻止你做他们不希望你做的事情。 他们甚至可以用它来区分“基本”(许多限制)托pipe和“企业”(很less限制)托pipe,这给CAS提供了全部的其他意义。

CAS的其他应用

对于我自己遇到的一些真实世界的情况来说,这么多。 我最近做的一个项目有类似的东西:允许用户上传一个库,并testing它的性能(“谁制造最好的algorithm”)。 不用说,我们在那里需要大量的CAS。 其他例子或有趣的资源:

  • NAR加载程序 (一个代码项目应用程序)使用它自己的CAS
  • LR评估者 (也是codeproject应用程序)使用CAS
  • ClickOnce(见下文)使用CAS
  • CASdevise模式 :它正在普及“假设”CAS被使用
  • 了解CAS :更大的受欢迎程度和一些意见意味着应用程序
  • 微软SharePoint一路使用CAS ,似乎(对不起,我不是SP的专家)

对于任何情况下,你只是完全控制自己,你build立自己的应用程序和代码(或build立),并完全控制你的系统,我不认为你会经常需要CAS。 这是更多的东西,你会用来从较不受信任的来源(这基本上是不是在你的完全控制的所有东西)运行代码。

CAS与ClickOnce

默认CAS设置限制从networking共享或其他非本地源运行代码的function。 这是有道理的,但严格的限制使得很难有一个分布式应用程序的中央存储库。 .NET 2.0引入了ClickOnce,这应该是为了提高安全性( 这里的讨论 )。

ClickOnce本身使用CAS ,以防止安装程序调用系统函数。 因此,我相信它可以说是最依赖于CAS的众所周知的应用程序

要点是:您需要了解CAS,以便能够创build可以直接从共享中运行的内容,或者您​​可以忽略所有内容并使用ClickOnce。

微软的CAS调查

微软在2005年召开了一次调查,以了解中国科学院为什么如此不受欢迎,希望改进它以使其更好地适用。 不幸的是,我找不到实际的调查结果,除了这篇文章稍微详细说明为什么CAS被滥用。

CAS在另一个世界

然而,这篇文章确实指出了一个有趣的地方:CAS适用于另一个世界:Unix / Linux。 他们不叫它CAS,而是它的BitFrost 。 对于一个真实世界的应用程序来说,这是如何: “每个孩子一台笔记本电脑”项目 ,它依靠BitFrost作为传统Unix安全模型的替代品。

更新:关于CAS在Unix / Linux中的BitFrost部分和调查部分。
更新:添加CAS与ClickOnce部分
更新:使用CAS添加资源列表(并连续道歉所有这些更新!)

从技术上讲,这是非常有用的,因为它允许非常细粒度的权限规范。 这对你是有好处的(理论上它使得利用安全漏洞更加困难 – 即使攻击者完全控制你的应用程序,他仍然被locking在CAS Sandbox中)和你的客户(因为他们可以看到你的应用程序可以执行自己的安全审计)。

在实际使用中,这几乎是毫无意义的。 我认为它太复杂了,可用的开发工具支持得太less,大多数用户都不在乎。

当然也有例外(政府和客户谁真正了解.net / CAS),我想说CAS是绝对有用和强制性的,但现实说话语言清晰。

请注意读者:请参阅以下两条评论。 这听起来像我不小心夸大了CAS的定义(错误地)包括RBS。 我将把答案留在这里作为参考,但请注意区别。


CAS有两个琐事; 在考试中你会看到最多的东西就是调用其他代码的代码的细微差别,这对于部分信任可能是有用的,但是大多数情况下这只是一个痛苦 – 而且更糟的是:如果你的代码完全信任哪个最/太多) 没有实际执行 (它被完全跳过)。

CAS RBS的有用部分是主要许可, 当然,你的用户界面应该validation对function的访问,但是你可以把(在你的自下而上的逻辑中):

[PrincipalPermission(SecurityAction.Demand, Role = "ADMIN")] static void DeleteOrder(int id) { ... } 

即使完全信任,这也会被执行。 你可以通过实现IPrincipal来定义你自己的主体(绑定到用户)(查看IsInRole() )。 而且由于主体在大多数环境(winforms,webforms,mvc,wcf等)中都得到支持,因此可以非常灵活地在业务层仔细检查安全性, 而无需引用特定的安全模型 。 请注意,上述检查可以在任何环境下工作。

你也可以用它来驱动你的用户界面。 我有一个usenet的post,启用/禁用基于主体的winforms控件(使用运行时属性来指定每个控件的angular色,有点像ToolTip等) – 虽然我不能在一分钟find它(编辑: 也许这个一个 )。

关于Code Access安全性的一点是,对于应用程序开发人员来说,这些应用程序开发人员的用处非常小,无法理解如何使用它,以及您可能调用的API的权限级别。 唯一的例外,我真正发现有用的是一个叫做PrincipalPermission的CAS,如果没有为当前Principal定义正确的angular色,它基本上不允许执行某些代码。 看到这个post:

http://www.coderjournal.com/2008/03/securing-mvc-controller-actions/

真正需要关注CAS的开发人员以及应用程序如何在应用程序中实现的是框架和代码库开发人员。 因为您需要特定的信任级别,以便您的应用程序能够正常工作,特别是在处理非托pipe资源(如文件,networkingstream,串行端口等)时。或者,如果要为某些特定的非托pipe资源创build代码服务器或任何types的低级别的访问到你的程序集中,你会想创build一些代码访问安全性,以便人们不被允许执行被严格拒绝的东西。

微软并没有真正做到这一点,说明如何在每天的应用程序中使用CAS。 所以这就是缺乏使用的原因。 然而,CAS是.NET的一个如此安全的语言,并且比竞争对手的问题less得多。

我是一个基于.NET的解决scheme获得JITCauthentication (美国国防部) authentication的项目的开发主pipe,在authenticationtesting期间,CAS设置进行了非常仔细的审查。

像大多数其他authentication要求一样,代码只能使用它需要的权限才能工作,不能再使用。

如果您计划获得安全authentication,CAS肯定是重要的。

有一点你应该知道的是,代码访问安全性作为一种防篡改方法已经非常糟糕。 看到:

CAS防篡改被破坏:软件许可的后果

不能再依赖代码访问安全来防止在出货产品中使用篡改组件。 这意味着,如果您的应用程序依赖于代码访问安全性来执行许可检查,那么攻击者就可以用另一个替代您的授权程序集,这样就可以免费访问您的应用程序。

虽然我从来没有用过,但我对CAS的理解是,它也可以用来扩展面向对象的devise机制。 例如,假设您正在为银行开发海量数据访问软件包,该软件包必须实施数据库访问和caching。 尽pipe它们是同一个部署包的一部分,但假定项目的大小是假定的,逻辑应该在单独的程序集中实现,因为它们是依赖于不同外部力量(数据库基础结构与消费者使用)的足够不同的问题集合。

但是,caching代码可能需要访问数据访问程序集中的一些敏感类或方法,整个程序包的使用者不应该有权访问这些类或方法。 因此这些数据访问类和方法不能简单地public 。 数据访问程序集中的受保护的方法在高速caching程序集中具有子类,可以解决某些情况,但通常这是滥用inheritance。 使用自定义权限(例如DataPackagePermisson )的调用方上的LinkDemands将其public ,pipe理员只会将其授予caching程序集,这可能更简单一些。

我们使用CAS作为我们的应用程序并不是很难,因为我们只是试图阻止未经授权的代码执行。 一旦使用我们的本地networking共享软件,问题就出现了,但是一个cas策略清除了这个问题。

  1. 我们用强大的名字保证了我们所有的组件。
  2. 我们为所有具有强名称的程序集创build了一个cas程序策略,并允许使用强名称签名的代码从局域网和本地代码开始。
  3. 从需要本地文件访问的局域网加载的程序集(用于刻录数据CD的组件)需要获取所有公共类的链接需求属性。

由于.NET3.5的更新,我们的问题不再存在,因为局域网上的代码现在像本地代码一样处理。