.NET Security Blog : Silverlight

Differences Between the Security Rule Sets

shawnfa — Thu, 12 Nov 2009 20:59:00 GMT

In my last post I talked about the two different security rule sets supported by the v4 CLR. At a high level, level 1 is the v2.0 security transparency model, and level 2 encompasses the updated v4 security transparency model. Digging down a little deeper, it’s interesting to look at some of the exact details that change between the various transparency models. For fun, let’s also compare both rule sets to Silverlight.

A couple of interesting things to notice – the level 2 rules look quite similar to the Silverlight rules. This means that you can basically learn one set of core security enforcement rules and apply them to both desktop and Silverlight development. As I mentioned previously, it’s also interesting to note that the penalty for transparency violations in level 2 transparency are generally hard failures, while the penalty in level 1 was generally triggering a full trust demand. That means that many of the level 1 transparency violations are generally more expensive (since they incur a runtime check at each invocation, rather than a single JIT time check). They also have a tendency to hide on you, since runtime checks can sometimes succeed during testing, and fail once you deploy your app to a new environment.

In the interest of completeness, I’m going to list several things in this table that I have yet to blog about. (Although, you’ll recognize many of the core transparency rules covered here.) Over the next few weeks, I should cover the various interesting pieces of this table – but rather than waiting to blog about them before adding them here, I think it would be more useful to list the full table now.

I’ll also note that while level 1 transparency is supported in the v4 runtime, it exists solely for compatibility with existing code. No new code should be written using the level 1 rule set, and over time existing code should consider moving to the level 2 rule set as well. (That is, don’t necessarily treat this chart as a way to select which security rule set you want to work with, but rather as a way to compare the evolution of transparency from .NET 2.0, to Silverlight 2, and finally into .NET 4).

	Level 1 (v2)	Level 2 (v4)	Silverlight 2
Introduced in	.NET 2.0	.NET 4	Silverlight 2
Default for	Assemblies built against runtimes prior to v4	Assemblies built against the v4 runtime	Silverlight assemblies
Explicit attribute	[assembly: SecurityRules(SecurityRuleSet.Level1)]	[assembly: SecurityRules(SecurityRuleSet.Level2)]	N/A – all assemblies use the Silverlight transparency model
Attribute to create a mixed transparency assembly (containing a combination of critical, safe critical, and transparent code in a single assembly)	[assembly: SecurityCritical(SecurityCriticalScope.Explicit)]	[assembly: AllowPartiallyTrustedCallers]	N/A – platform assemblies are all mixed transparency, application assemblies are all fully transparent
Effect of the APTCA attribute	Allows partial trusted callers access to the assembly by removing an implicit link demand for full trust on all code in signed assemblies.	Allows partial trusted callers access to the assembly by making all code in the assembly transparent by default. (Although the assembly can explicitly make some of the code critical or safe critical.)	N/A – Silverlight does not have the AllowPartiallyTrustedCallers attribute
Publicly visible security critical members are implicitly safe critical	Yes – there is no such thing as a publicly visible safe critical API in level 1 transparency.	No – only APIs explicitly annotated as SecuritySafeCritical are safe critical.	No – only APIs explicitly annotated as SecuritySafeCritical are safe critical.
Link demands should be used for JIT time security enforcement	Yes – since publicly visible critical APIs are implicitly safe critical, link demands must be used to prevent JIT time access to security sensitive APIs.	No – since code must be critical to access either a link demand or a public critical API, level 2 transparency deprecates the use of granular link demands in favor of simply protecting security sensitive APIs by keeping them security critical.	No – Silverlight does not support link demands.
Result if a transparent method attempts to call a method protected by a link demand	The link demand is converted into a full demand at runtime, which may fail with a SecurityException.	A MethodAccessException will be thrown at JIT time.	N/A – Silverlight does not support link demands.
Result if a transparent method attempts to call unmanaged code	A demand for SecurityPermission/UnmanagedCode will be triggered at runtime, which may fail with a SecurityException.	A MethodAccessException will be thrown at JIT time.	A MethodAccessException will be thrown at JIT time.
Result if a transparent method has unverifiable IL	A demand for SecurityPermission/UnmanagedCode will be triggered at runtime, which may fail with a SecurityException.	A VerificationException will be thrown at JIT time.	A VerificationException will be thrown at JIT time.
Result if a transparent method attempts to perform a security assert	An InvalidOperationException is thrown at runtime.	An InvalidOperationException is thrown at runtime.	N/A – Silverlight does not support security asserts.
Result if at transparent attempts to call a critical method	If the method is: Within the same assembly – a MethodAccessException is thrown at JIT time. In another level 1 assembly – N/A (level 1 publicly visible critical code is implicitly safe critical, so there is no violation). In a level 2 assembly – the critical code is treated as safe critical with a link demand for full trust. This, in turn, triggers a runtime demand for full trust which may fail with a SecurityException.	A MethodAccessException is thrown at JIT time.	A MethodAccessException is thrown at JIT time.
Transparency of partial trust assemblies	Fully transparent – all transparency annotations are ignored for partial trust assemblies.	Fully transparent – all transparency annotations are ignored for partial trust assemblies.	Application assemblies are fully transparent – all transparency annotations are ignored for them.
Default transparency for assemblies which are security agnostic	All types are transparent, all methods are safe critical.	All types and methods are security critical (except where this would violate inheritance rules).	N/A – all Silverlight assemblies are exposed to the sandbox.
Protection for non-APTCA assemblies being used by partial trust code	Provided to all signed assemblies by adding an implicit link demand for full trust to all code within the signed assembly.	Provided to all fully trusted assemblies because all of the types and methods within a non-APTCA assembly are security critical by default (see above).	N/A – all Silverlight assemblies are exposed to the sandbox.
Fully transparent assemblies are exposed to partial trust	No – signed fully transparent assemblies still have an implicit link demand for full trust unless they are additionally marked APTCA	Yes – no additional APTCA attribute is required for fully transparent code.	Yes
Critical members can be converted to safe critical members protected by a link demand for FullTrust	No	Yes. If a publicly visible security critical method is called by a security transparent level 1 method, the CLR will treat the critical method as if it was safe critical with a link demand for full trust on it. (If the caller is level 2, this conversion does not occur).	No
Security critical annotations support both applying to a larger scope (type, assembly, etc) and all of its contained members, or only the scope itself	Yes. The SecurityCriticalScope enumeration is used to toggle between having a SecurityCritical attribute apply to only the container (SecurityCriticalScope.Explicit) or the container and all of its members (SecurityCriticalScope.Everything)	No. SecurityCriticalScope is not used in level 2 assemblies, and is ignored if it is provided. All security critical attributes implicitly use SecurityCriticalScope.Everything.	No. All SecurityCritical attributes implicitly use SecurityCriticalScope.Everything.
Members introduced within a security critical scope can add additional attributes to become safe critical	Yes. Adding a SecurityTreatAsSafe or SecuritySafeCritical attribute within a critical scope changed the contained member’s transparency.	No. The larger scope always wins, attributes applied at smaller scopes are not considered.	No. The larger scope always wins, attributes applied at smaller scopes are not considered.
Critical or safe critical annotations at a larger scope (type, assembly, etc) introduce only to methods introduced directly in a type. Overridden virtuals and interface implementations do not use the larger scoped annotation and are transparent by default.	No, the outer scope applies to all contained members.	Yes. Since the transparency of the members not introduced by the local type are not under its direct control, overrides and interface implementations must restate their intended transparency.	Yes.
Can define security critical attributes that are protected from use by partial trust code	No. Link demands must be used for this purpose.	Yes. Security critical attributes cannot be applied to transparent targets.	Yes.
If reflected upon, security critical targets trigger a security demand	No, although link demands do become full demands under reflection.	Yes. Reflecting upon a level 2 security critical target will trigger a full demand for full trust. This happens based upon the target of the reflection, not based upon the code that is performing the reflection operation. (For example, level 1 code reflecting on a level 2 critical method will still trigger the demand).	Yes. Transparent code may not reflect upon critical code.
Delegate binding rules are enforced	No.	No.	Yes – Silverlight contains delegate binding rules that prevent critical delegates from being bound to transparent targets and vice versa.

MD5 on Silverlight

shawnfa — Wed, 10 Dec 2008 04:39:03 GMT

Reid Borsuk, an SDE/T on the CLR security team, has released a fully transparent implementation of the MD5 hash algorithm to the MSDN Code Gallery. Since the code is entirely transparent, it can be used as part of a Silverlight application that needs to compute MD5 hashes in order to interop with existing code or file formats that requires MD5.

He's also released an MD5Managed type to wrap around his implementation, in case you want to plug the algorithm into the standard .NET hash object model.

Dr. Dobbs Looks at Silverlight Security

shawnfa — Wed, 09 Jul 2008 21:07:28 GMT

Dino Esposito has an article in the March Dr. Dobb's Journal taking a look at the Silverlight platform from a security perspective: The Silverlight 2.0 Security Model. The second half in particular boils down some of the details of the transparency model used for security enforcement in Silverlight. This article is quite good - I definitely recommend a read.

In his article, Dino talks about the SecuritySafeCritical attribute as compared to the SecurityTreatAsSafe attribute, and points out that on the desktop framework any public critical method is implicitly TreatAsSafe. He mentions that one of the reasons we didn't bring TreatAsSafe over to the Silverlight BCL is that this is not true on Silverlight.

To add to this, there's one other thing that made The other thing that made us decide that SafeCritical would be better than TreatAsSafe was that the only time TreatAsSafe really makes sense is when you're combining it with SecurityCritical. A TreatAsSafe transparent method, for instance, doesn't buy you anything. Since 95% of the cases where the TreatAsSafe attribute was being used also used the SecurityCritical attribute, we decided to merge the two into a single attribute - SecuritySafeCritical.

Silverlight Security Cheat Sheet

shawnfa — Mon, 14 May 2007 18:45:52 GMT

Over the last week we took a look at the new Silverlight security model. When you're writing a Silverlight application though, there's a lot of information there that you may not want to wade through to get yourself unblocked. Here's a quick cheat sheet highlighting the important points that you'll need to know when working with the Silverlight security model:

All applications written for Silverlight are security transparent. This means that they cannot: [details]
- Contain unverifiable code
- Call native code directly
Silverlight applications can access public methods exposed by platform assemblies which are either: [details]
- Security transparent (neither the defining type nor the method has any security attributes)
- Security safe critical (the method has a SecuritySafeCriticalAttribute)
Silverlight applications may contain types which derive from: [details]
- Other types defined in the application
- Unsealed, public, security transparent types and interfaces defined by the platform
Silverlight applications may contain types which override virtual methods and implements interface methods which are: [details]
- Defined in the application itself
- Defined by the platform and are transparent or safe critical

Silverlight Security III: Inheritance

shawnfa — Fri, 11 May 2007 18:12:23 GMT

Over the last few days we've looked at the basics of the CoreCLR security model in Silverlight, and how to tell which platform APIs are available for applications to call. Let's wrap up this mini-series on CoreCLR security by looking at how the CoreCLR transparency model interacts with inheritance in the Silverlight platform.

From what we already know, we can define a logical ordering among the transparency levels:

Transparent (application / platform)
Safe critical (platform only)
Critical (platform only)

What's all this got to do with inheritance? This ordering becomes very important when determining if a class is allowed to derive from a parent class. A class may only derive from a type at its level in that ladder or higher. It may never derive from a base class lower on the ladder. This means, for instance, that critical types can derive from any other type while a transparent type may only derive from other transparent types.

We can apply this to types in a Silverlight application relatively easily. Since all application code is transparent, it stands to reason that all of the types in application assemblies are also transparent. Applying this rule, we see that application types may only derive from other application types or transparent platform types. (*)

In the same way that the security rules for method access are on top of the standard runtime access rules, the rules for inheritance are also in addition to the standard runtime inheritance rules. So an application type may not derive from a sealed transparent type in a platform assembly for instance, since the CLR does not allow derivation from sealed types.

One of the more interesting things to do once you've derived from a type is to start overriding virtual methods (or implementing interface methods). Not surprisingly, we have security checks for these overrides as well which are also based upon the transparency model. When talking about overriding methods, it's convenient to group the different security groups into two accessibility levels:

Transparent and safe critical code
Critical code

When grouped this way, we see that transparent code has access to everything in the first level while only critical (including safe critical) code has access to the second level.

With that in mind, the simple rule is that a method may only be overridden by another method in the same accessibility level. So a Silverlight application may override any virtual from within their application, as well as any transparent or safe critical platform virtuals. (Assuming, of course, that the application type was allowed to derive from the platform type).

The same rule applies when it comes to interface implementations. A Silverlight application may implement all methods on any interface defined by the application itself. If the interface is supplied by a platform assembly, then the application my only implement methods which are either transparent or safe critical. Practically speaking this means that Silverlight applications may not implement any interface which contains any critical members.

We can summarize the CoreCLR security inheritance rules for applications into three quick rules:

Types may only derive from base types that are transparent.
Only transparent or safe critical methods may be overridden
Only transparent or safe critical interface methods may be implemented

(*) This true in 99.9% case. There is another rule about the visibility of the default constructor of a class (which we'll get into next week when we dig deeper into the security model), which also requires that the base class' default constructor (if it has one), must be transparent as well. Practically speaking, you're not generally going to find interesting transparent types in the platform which do not also have transparent default constructors, so this rule doesn't normally come into play.

Silverlight Security II: What Makes a Method Critical

shawnfa — Thu, 10 May 2007 18:33:00 GMT

Yesterday we talked about the CoreCLR security model, and how it is built upon the transparency model introduced in the v2.0 .NET Framework. The quick summary was that all Silverlight application code is transparent, and transparent code may only call other transparent code and safe critical code. With that in mind, lets take a look at figuring out how can tell which platform APIs fall into each category ... allowing us to know which APIs our applications are allowed to call.

In Silverlight, by default all code is transparent. (This is different from the desktop CLR, where all code is critical by default). For application code, that's the end of the story -- as we said yesterday, a fundamental tenant of the CoreCLR security model is that all application code is transparent.

Platform code can be either transparent, safe critical, or critical however. CoreCLR will detect platform code by knowing where the assembly is loaded from (platform assemblies must be loaded from the Silverlight installation directory), and also by checking the assembly's public key. Only assemblies signed with specific Microsoft's public keys will be considered platform assemblies; because of this public key requirement, no Silverlight application code can ever be considered a platform assembly.

We can tell if a method is security critical or transparent by looking at the attributes on the method in question (and on the class that contains the method). To simplify this discussion, I'll talk directly about attributes on methods, however if the class containing the method has one of the security attributes, then this attribute will apply to every method within the class.

If a method in a platform assembly is marked with the SecurityCriticalAttribute, this means that it contains critical code. Even if the method is public, no application code can call it since transparent code may never directly call into critical code. Any attempt to break this rule will lead to a MethodAccessException at runtime.

For example, the constructor for FileStream in the Silverlight 1.1 alpha bits (snipped below) is security critical which we can see from the SecurityCriticalAttribute on line 5:

    1   .method public hidebysig specialname rtspecialname

    2           instance void  .ctor(string path,

    3                                valuetype System.IO.FileMode mode) cil managed

    4   {

    5     .custom instance void System.Security.SecurityCriticalAttribute::.ctor() = ( 01 00 00 00 )

    7     // ...

    8   }

Similarly, every method in the Marshal class is also critical, since the entire class is marked with the SecurityCriticalAttribute on line 4:

    1 .class public abstract auto ansi sealed beforefieldinit System.Runtime.InteropServices.Marshal

    2        extends System.Object

    3 {

    4   .custom instance void System.Security.SecurityCriticalAttribute::.ctor() = ( 01 00 00 00 )

    6   // ...

    7 } // end of class System.Runtime.InteropServices.Marshal

A method in a platform assembly marked with the SecuritySafeCriticalAttribute is, of course, safe critical. Application code may call into these methods, since transparent code may call safe critical code. And since safe critical code is critical, it can then turn around and call critical APIs on behalf of the application.

One example of a safe critical API is the IsolatedStorageFileStream.Write, which we can see on line 6 of its disassembly:

    1   .method public hidebysig virtual instance void

    2           Write(uint8[] buffer,

    3                 int32 offset,

    4                 int32 count) cil managed

    5   {

    6     .custom instance void System.Security.SecuritySafeCriticalAttribute::.ctor() = ( 01 00 00 00 )

    8     // ...

    9   }

An interesting note is that the SecuritySafeCriticalAttribute is really just a combination of the desktop framework's SecurityCriticalAttribute and SecurityTreatAsSafeAttribute. If you're familiar with the desktop CLR's transparency model, then you'll know that the TreatAsSafe attribute is implied for all public critical methods. This is not true in the CoreCLR security model for Silverlight -- instead, safe critical methods must be explicitly marked.

Since there are no more implicit treat as safe methods, the need to explicitly annotate a method with both the SecurityCritical and the SecurityTreatAsSafe attributes became much more common, so SecuritySafeCritical was introduced as a shortcut; it saves time when typing and also reduces metadata size. However, if you are familiar with the desktop CLR transparency model, it's safe to read "SecuritySafeCritical" as "SecurityCritical, SecurityTreatAsSafe" when reasoning about an API set.

If a method has neither the SecurityCritical attribute nor the SecuritySafeCritical attribute applied to it, then the method must be transparent (since we said above that all code is transparent by default). If this method is visible to the application code, that means that the application can call into it because transparent code is always allowed to call other transparent code.

Incidentally, if a Silverlight application tries to be tricky and mark itself with one of the SecurityCritical or SecuritySafeCritical attributes nothing will happen. The CLR knows that application code must be transparent, so it doesn't even bother to look for those two attributes when examining a method from a non-platform assembly. Instead, the method with the disallowed attributes will continue to be treated as transparent, and if they try to do anything that is not allowed from a transparent method, an exception will be thrown.

Finally, it's important to note that these rules do not replace the standard public / private / protected / internal access rules for the runtime; instead they supplement them. So application code may not call an internal method in a platform assembly, even if the method is transparent.

To summarize:

	Security Attribute	Means	Directly callable by application code (if the method is visible)
Application Code	-	Transparent	Yes
Platform	None	Transparent	Yes
Platform	SecuritySafeCritical	Safe critical	Yes
Platform	SecurityCritical	Critical	No

Next time, we'll look at how this security model interacts with inheritance.

The Silverlight Security Model

shawnfa — Wed, 09 May 2007 18:07:45 GMT

You may have heard a thing or two last week about a little project we like to call Silverlight, including a small version of the CLR that will run in the browser on both Windows and the Mac. (If you haven't grabbed the Silverlight v1.1 alpha bits yet, I highly recommend it -- as well as grabbing the SDK and heading over to the quickstarts site and forums so that you can try it out for yourself).

Since the v1.1 release of Silverlight includes a slimmed down version of the CLR, you might be wondering what the managed security story for Silverlight is and how it compares to CAS on the desktop version of the CLR.

The good news for everyone who's spent hours deciphering cryptic caspol commands is that Silverlight removes CAS entirely. Instead, the security model is based around an enhanced version of the v2.0 transparency model. When I say CAS is gone, I mean it's really gone -- there are no permissions, no policy levels, and no stack walks in CoreCLR. The System.Security namespace is pretty barren indeed! (But wait -- why is SecurityPermission still exposed from mscorlib then? It turns out that the C# compiler will emit a RequestMinimum for SkipVerification if your assembly contains unverifiable code. Since we need to be able to use the existing C# compiler to create Silverlight assemblies, we had to keep that one permission in the public surface area).

In place of CAS, the CoreCLR security model can be boiled down to the following two statements:

All user code that runs on CoreCLR is entirely transparent
Platform code may contain both transparent and critical code; it is responsible for providing a gateway for transparent code to safely access various system services.

Which means that the essence of the CoreCLR security model is that Silverlight applications may not contain unverifiable code and may only call transparent or safe critical APIs exposed from the platform. Let's dig a little deeper into this.

Since transparency forms the, ahem, core of the CoreCLR security model, let's take a minute to refresh the basics of what transparency means, starting with the model we already know on the v2.0 framework. Transparent code is code which cannot perform any actions that would elevate the permissions of the call stack. Essentially, security transparent code cannot cause any security check to succeed (although it can cause them to fail); so you can think of it as running with the permissions of its caller. The opposite of transparent code is critical code, and assemblies may contain a combination of transparent and critical code. Individual methods may only be transparent or critical however; they cannot contain a mix of both.

The specific restrictions placed upon security transparent code is that it may not:

Satisfy a LinkDemand
Perform a CAS Assert
Contain unverifiable code
Call native code via a P/Invoke or COM Interop
Access critical code or data which does not specifically allow it.

So let's start to translate this to the Silverlight world. We know that there's no such thing as CAS in Silverlight, so the first two restrictions don't make sense there. (Without CAS there are no permissions to assert or do a demand for, even just a LinkDemand). On the desktop CLR, the next two restrictions are enforced by injecting a demand for UnmanagedCode. Since we don't have a concept of demands in Silverlight, that enforcement mechanism isn't appropriate, and instead we just throw a MethodAccessException if transparent code tries to violate one of these rules.

The last rule is the most interesting in the group. If transparent code attempts to directly call critical code, a MethodAccessException will be thrown. However, most of the interesting system services are required to be implemented in critical code (for instance, in order to access the file system, we need to P/Invoke to the operating system's file IO APIs. Since calling native code is only available to critical code, any APIs which write to the file system must therefore be critical). If that's the case, how does a Silverlight application access any of these interesting services?

This is accomplished by having an intermediate layer of safe critical code that act as gate keepers for the critical methods, ensuring that it is safe for the transparent code to perform the operation that it is asking to do. These safe critical APIs may do various checks before passing control to a critical API, including validating incoming parameters and ensuring that the application state is acceptable for this call to continue. Since safe critical methods are in fact critical code, once they ensure that the caller is allowed to proceed they are allowed to invoke a critical method on the caller's behalf.

For example, earlier I mentioned that file IO must be implemented as critical code. Being able to have some form of persistent storage is useful for an application however, so we'll need a safe critical layer that transparent code can call, and after ensuring that the call is valid will pass on requests to the critical file IO layer. In Silverlight, this safe critical layer is IsolatedStorage. When a Silverlight application calls IsolatedStorage, the IsolatedStorage APIs will validate the request by making sure that the Silverlight application is requesting a valid file and is not over its quota. Then it calls the critical file APIs to perform the actual work of reading or writing to disk.

You can think of this as being very similar to an operating system model. In that analogy:

Operating System	CoreCLR	IsolatedStorage Example
User mode code	Transparent code	Silverlight application
System call	Safe critical API	System.IO.IsolatedStorage
Kernel code	Critical API	System.IO.FileStream

In the same way that applications running on Windows or the Mac cannot call directly into the kernel of the operating system without passing through a system call layer, Silverlight applications cannot directly call critical code without passing through a safe critical layer. In the file IO example, a Silverlight application may not directly write to disk without first passing through the IsolatedStorage layer.

That's a lot of information -- but thankfully it can be summed up very easily: The CoreCLR security model in Silverlight is that all Silverlight applications consist of entirely security transparent code, and this security transparent code may only call other transparent code or safe critical code.

Over the next few posts, we'll explore a few more details of the security model, such as how to tell what code is transparent and critical and some new rules regarding inheritance.