MSDN Magazine - October 2008 - (Page 20) Figure 3 Comparing Transparent, SafeCritical, and Critical Code Transparent Access Restrictions Cannot directly call Critical code. SafeCritical Can do everything that Critical code can. Must make sure to perform the applicable checks before and after calling into Critical code. Critical Is privileged and able to call any code. Equivalent of full trust only. Can never be called directly by Transparent code, but may be exposed via SafeCritical code. May contain unsafe or unverifiable code. Only available to Silverlight platform assemblies. Types can derive from all types regardless of annotations. Methods must derive from Critical virtual/interface methods. Unsafe Code Availability to Application or Platform Code Type Inheritance Characteristics Method Override Characteristics Cannot contain unsafe or unverifiable code. Present in both application and platform code. Types must derive from other Transparent types. Methods must override Transparent or SafeCritical virtual/interface methods. May contain unsafe or unverifiable code. Only available to Silverlight platform assemblies. Types must derive from Transparent or SafeCritical types. Methods must derive from Transparent or SafeCritical virtual/interface methods. To summarize the Silverlight Transparency model, remember that all code is Transparent by default. All Silverlight applications are completely Transparent. All markings indicating otherwise are ignored. In addition, a fixed permission set means Transparency is the only enforcement mechanism needed for CoreCLR. Figure 3 summarizes the three types of code and their abilities and traits. Exposure to Silverlight Transparency Much of the benefit of the Silverlight Transparency model manifested itself in the simplicity of security enforcement in the Silverlight platform. Since Silverlight is a closed platform, there is currently no notion of trusted third-party libraries. Therefore, a developer’s interaction with the Silverlight Transparency model is limited to the APIs he is allowed to call—those that are Transparent or SafeCritical—as his applications are completely Transparent. On the .NET Framework, however, the platform is not closed, and so it is possible to develop additional libraries that could benefit from simpler security enforcement. However, developers may see these benefits in the next major release of the desktop framework. The Transparency model we introduced in .NET Framework 2.0 made the tasks of analyzing and judging the security of APTCA libraries much simpler; the Silverlight Transparency model took that another step up, allowing us to make assumptions and guarantees that previously had to be confirmed through painstaking review. In the future, we plan to introduce the tightened rules around Transparent code, the SafeCritical attribute, and the Transparency inheritance rules to the full .NET Framework. We also plan to make them available to external developers as well. One major difference between the desktop framework and Silverlight is that most applications on the desktop framework are built for full-trust environments, while all Silverlight applications are built for a partial-trust environment. Most desktop applications can do anything they want and would continue to be able to do so—they won’t have to think about Transparency at all. Implementationwise, these applications will be considered Critical. 20 msdn magazine APTCA library developers will experience many of the benefits of our Silverlight platform assemblies. The auditable surface area of an APTCA library is now focused on the SafeCritical layer, as the Critical layer is not accessible from partially trusted, Transparent code. Furthermore, the introduction of the inheritance rules ensures that the library overrides and derivatives aren’t unintentionally exposing any security holes. (Just keep in mind that, due to the fact that there’s a variety of possible sandboxes on the desktop framework, APTCA libraries will have to handle individual permissions. Therefore, SafeCritical APIs may have to perform permission demands as well as other input validation checks.) The stricter Transparent code rules also mean that partially trusted applications will be safer and more performant than before. In the .NET Framework 2.0 Transparency model, Transparent code that called or contained unsafe or unverifiable code faced injected demands for UnmanagedCodePermission and the expensive stack walk that resulted when the unsafe/unverifiable code was called. This typically results in a failure, as most sandboxes do not contain this permission in their permission grant sets. In the new Transparency model, these will be hard failures—as in the CoreCLR, there would be no injected demand and, therefore, no stack walk. By bringing the new Transparency model to the next version of the desktop framework, we hope to make it easier to develop APTCA libraries as well as improve the experience around developing partially trusted applications. Andrew dAi is a Program Manager for the CLR at Microsoft. He works on security for Silverlight and the desktop framework. CLr Inside Out
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.