Dela via

The Silverlight Security Model

  • Artikel

Silverlight

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:

  1. All user code that runs on CoreCLR is entirely transparent
  2. 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:

  1. Satisfy a LinkDemand
  2. Perform a CAS Assert
  3. Contain unverifiable code
  4. Call native code via a P/Invoke or COM Interop
  5. 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.

Comments

  • Anonymous
    May 09, 2007
    I think we can say: Goodbye CAS! This post explains the new security model used on the new Silverlight

  • Anonymous
    May 09, 2007
    Since the v1.1 release of Silverlight includes a slimmed down version of the CLR, you might be wondering

  • Anonymous
    May 10, 2007
    Yesterday we talked about the CoreCLR security model , and how it is built upon the transparency model

  • Anonymous
    May 10, 2007
    How does it call javascript? Can I use a javascript function to call COM from Silverlight?

  • Anonymous
    May 10, 2007
    Since stack walking is out, does that mean tails calls are now just as efficient as ordinary calls?

  • Anonymous
    May 10, 2007
    Since the runtime cannot call Javascript directly, you would need a library in the middle to enable this.  This library would have to talk to the browser object model, which means that it needs to invoke native code -- meaning it must be critical code. Therefore the library must expose a safe critical layer for your application to call if this were to be possible. Silverlight v1.1 alpha does have a library that enables interacting with the DOM of the hosting web page, although unfortunately I don't know if it allows this specific scenario. (Check out the System.Windows.Browser namespace in System.Silverlight.dll) -Shawn

  • Anonymous
    May 10, 2007
    The only interaction between tail calls and the CLR security system on the desktop is that you could not tail call out of a method that was involved in security state. Since none of your methods will be doing Denies or Asserts, then you can assume that the tail call implementation is free to ignore security on Silverlight. :-) -Shawn

  • Anonymous
    May 10, 2007
    Ok, jeder spricht die Tage über Silverlight - doch wie sieht das Sicherheitsmodell dahinter aus? Kollege

  • Anonymous
    May 11, 2007
    Over the last few days we've looked at the basics of the CoreCLR security model in Silverlight , and

  • Anonymous
    May 14, 2007
    Over the last week we took a look at the new Silverlight security model. When you're writing a Silverlight

  • Anonymous
    May 14, 2007
    The Silverlight Security Model Silverlight Security II: What Makes a Method Critical Silverlight Security...

  • Anonymous
    June 05, 2007
    a {color : #0033CC;} a:link {color: #0033CC;} a:visited.local {color: #0033CC;} a:visited {color : #800080;}