从.NET Framework 1.0 开始,微软就引入代码访问安全(CAS)模型,这是一项用于分配和管理托管代码的工具。.NET Framework 4.0 Beta 2 并不赞成使用CAS,故默认情况下已经关闭该功能,而引入了第二级安全透明度的( Security Transparency Level 2 )安全模型。
考虑到一项强大的功能可以帮助.NET 比 Java 取得更大的进展,在.NET 开发人员中 CAS 就变得不太流行,这是由于它自身的复杂性以及使用不当时会导致潜在的安全漏洞所致。除此以外,本地应用程序或者非托管代码可在完全信任的情况下继续运行,这让 CAS 更无用武之地。
.NET Framework 4.0 中关闭 CAS,表明所有通过 Windows Explorer 或者命令行运行的程序都处于完全可信状态。在 IE 浏览器或 ASP.NET 内部运行的.NET 应用程序也会由它们的主机授于某种级别的信任度。
基于这项改变,当前开发中的代码也许会弹出警告或运行时异常:
这些安全策略改变的结果是:如果我们通过其他类型及成员显式或隐式调用过时的 CAS 安全策略类型和成员,我们也许会遇到编译警告和运行时异常。对于过时的类型和成员以及其替代者,请查看:代码访问安全策略的兼容性与移植。
我们可以在运行时设置框架使用 <NetFx40_LegacySecurityPolicy> 配置要素来加入早期的 CAS 策略操作,以绕开警告或错误提示。然而,指定使用旧版安全策略并不包括该版本的任何自定义 CAS 策略,除非它移植到.NET Framework 4 Beta 2。
.NET 4.0 Beta 2 扩展了早期的 Security Transparency 功能,该项功能首次在.NET 2.0 中引入并在微软内部使用。托管代码在一个沙盒中运行就认为是透明的,因为它仅执行主机授权的操作,所以认为它是安全的。第二级透明度安全模型引入以下新元素:
在.NET Framework 4 Beta 2,透明度是一项强制措施,用于把应用程序代码和底层代码分开。透明度区分了可调用本地代码的关键代码和和不可调用本地代码的透明代码。透明代码可在许可范围内执行命令操作,但不能执行、调用、派生自关键代码或包含关键代码。 透明度强制措施的初始目标是要提供简单而高效的机制来隔离不同权限的代码组。在沙盒模型中,这些权限组不是完全信任(即不受约束)就是部分信任(即受制于沙盒的许可进行设定)。
桌面应用程序是完全可信的。因此,它们不受透明度模型的影响。
在.NET 4.0 中有三种代码类型:透明代码、可靠和关键的安全代码和关键安全代码:
透明代码——包括完全可信的运行代码,仅可调用其他的透明代码或可靠和关键的安全代码。它仅执行主域中部分可信的许可集(如果存在的话)允许的操作。
- 执行断言或权限提升操作
- 包含不可靠或不可核实的代码
- 直接调用关键代码
- 调用本地代码或具有 SuppressUnmanagedCodeSecurityAttribute 属性的代码
- 调用受 LinkDemand 保护的成员
- 从关键类型继承
除此以外,透明方法不可以重写关键虚方法或实现关键接口方法
可靠和关键的代码完全可信,但由透明代码调用。它公开了完全可信代码的部分表层代码。修正和安全确认在可靠和关键的代码中执行
关键安全代码是完全可信的并可调用任何代码,但它不能由透明代码所调用
开发人员仍可使用 CAS,如果他们的应用程序适用于早期的.NET Framework 版本的话,但是他们不能使用在 4.0 Beta 2 或以后版本的最新功能。微软鼓励他们用 Windows 软件限制策略 (SRP) 来代替,它有更简单的安全机制来处理托管代码和本地应用程序。
查看英文原文: Code Access Security Is No Longer Used in .NET 4 Beta 2
评论