MSDN Magazine - October 2008 - (Page 19) These are significant simplifications Figure 1 Allowed Type Inheritance Patterns Transparent method even though it does that provide the following results: all nothing. Finally, having only one way to Base Type Allowed Derived Type Silverlight applications are Transparent specify safe, Critical code simplifies the Transparent Transparent, SafeCritical, and receive the Silverlight sandbox permodel further. Critical mission set, Silverlight platform librarOne thing to realize regarding this new SafeCritical SafeCritical, Critical ies (most of which are fully trusted) will attribute is that when we talk about CritCritical Critical only ever be called by Silverlight applicaical code, we often include SafeCritical tions, so we don’t need to demand code in the discussion. This is bespecific permissions; marking Figure 2 Allowed Method Inheritance Patterns cause SafeCritical code is Critidangerous APIs as Critical is cal code—it is just as capable as Base (Virtual/Interface) Method Allowed Override Method sufficient. Finally, since there Critical code, but it is also callable Transparent Transparent, SafeCritical are no demands, we will never by Transparent code. Therefore, Transparent, SafeCritical need to stop a permission stack SafeCritical to truly make it safe and CritiCritical Critical walk and, therefore, we don’t cal, the library developer must need asserts. be sure that the proper input Thus, Transparency becomes the sole security enforcement validation or other security checks are being made before Critical mechanism in CoreCLR, and we are able to ignore much of CAS. code (not safe) is called and that the necessary output validation To make it a stronger enforcement mechanism, we tightened the and side-effect checks are being made afterward. SafeCritical berules for Transparent code and made additional improvements to comes a contract that says this method accesses Critical code but the Transparency system to make it more intuitive and effective. does all the appropriate checks beforehand and afterword. With You may have noticed that in the 2.0 Transparency model, un- the new Transparency model, the focus of security audits is the safe or unverifiable code that executes in Transparent code causes SafeCritical code. an injected demand for UnmanagedCodePermission instead of an outright failure/exception. Generally, this permission should only Inheritance Rules be available in full trust, so this code would fail in partial trust but For the Transparency model to be effective, we also had to ensure work otherwise. that the closure of a type or method was secure as well. Deriving With CoreCLR, however, we don’t have the concept of permis- types or methods with resource access rights that were different from sion demands, so an exception will be thrown when this happens the rights of the base type or method raised some access protection (instead of a demand being injected in the new Transparency mod- issues, especially when these were being cast to more accessible parel). This type of code fails in both models, but is more performant ent types or interfaces. For example, you could imagine someone now since we don’t have to deal with the demand’s stack walk be- creating a Critical override of a Transparent virtual method, such fore finally failing. as ToString, and wanting to prevent Transparent code from callAlso, in Silverlight, all code is Transparent by default. This in- ing the override by casting to Object.ToString. cludes Silverlight platform libraries; all Critical code must be explicYou can imagine that there is an access and capability hierarchy itly annotated. This provides us with a secure default that reduces for Transparency levels whereby access becomes more restricted the chances of creating an implicitly Critical method accidentally. and/or capabilities are increased as you move from Transparent to More rules were added with regard to type inheritance and method SafeCritical to Critical. (Here access refers to the ability to contain overrides, which I’ll explain in the Inheritance Rules section. as well as call this level of code). The inheritance rule for types is I mentioned earlier that a Critical API marked TreatAsSafe was that derived types must be at least as restrictive as the base type. considered to be callable from Transparent code. I also pointed out This prevents developers from accidentally creating overloads of that, since Transparency on the desktop framework only applies Critical types callable by Transparent code. Figure 1 shows what’s within an assembly, public Critical APIs are implicitly TreatAsSafe. allowed according to this pattern. In CoreCLR, we created a new attribute, SafeCritical (again, the acThe virtual method override rule is different—the derived tual annotation is SecuritySafeCritical), to describe code that was method must have the same accessibility from Transparent code both Critical and callable from Transparent code. Transparency as the base method. Figure 2 shows what’s allowed according to now applies within and across assemblies, so Critical code, whether this pattern. public or not, cannot be called from Transparent code. Note that we don’t allow Critical overrides of Transparent virtual This change helps to clear up confusion around how to ex- methods—one could simply cast to the base method and bypass pose Critical code to Transparent code. First, all Critical code is the Critical check on the override when calling it. We allow Saferestricted—there is no exception for public code, so adding the Critical overrides of Transparent functions because the cast would Critical annotation will always mean that Transparent code can- buy you nothing—Transparent code can access SafeCritical code not call it. Furthermore, TreatAsSafe only ever makes sense if the anyway. We also allow Transparent overrides of SafeCritical virtual Critical attribute is already there—requiring two attributes may methods—this may seem surprising at first, but it’s actually safe belead to some confusion, as it is possible to put TreatAsSafe on a cause, again, nothing dangerous can be exposed via casts. msdnmagazine.com October 2008 19 http://www.msdnmagazine.com
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.