An important component of Silverlight is a simplified security system for protecting what can be done and what can not be done by user code.
.NET 1.x and 2.x have a system called the "Code Access Security" (CAS) which Mono has never completely implemented since it there are very few applications that actually took advantage of it (Update: On the comments someone points out that CAS is fundamental for any uses of ClickOnce deployment; Mono has no support for ClickOnce deployment either). This is probably due to its complexity, which leads to people not trying it out in the first place.
With Silverlight it becomes very important to ensure that we can execute code in a secure fashion and without allowing malicious code to get access to any resources on the system. Code that is downloaded and executed inside Silverlight/Moonlight needs to be sandboxed.
This new security system is described in a few blog entries from Shawn Farkas:
Today Mark posted his first implementation of this new security system for Mono for use in Moonlight:
Here's a preliminary patch for CoreCLR security, including a small patch for System.Security. It should do pretty much everything with the exception of catching method calls via reflection (I'm not sure how this is handles in Silverlight yet, and Silverlight on my Windows machine doesn't like me anymore - grr). I've included a small C# test program which tries out all the different ways (of which I'm aware) to call a method. That'll become a regression test eventually.
If mono is called with "--security=core-clr" then security attributes are only honored in system assemblies (those in $(PREFIX)/lib/mono/2.1) - other assemblies are always security transparent. To do better testing there's also an option "--security=core-clr-test" which honors security attributes in all assemblies.
Comments are welcome.
In addition to the new CoreCLR security system, the needs of Silverlight have finally pushed us to implement the code verifier in Mono. This is currently under development by Rodrigo.
CoreCLR is very similar to the design that Jim Pubrick has prototyped for SecondLife. Hopefully Jim can switch to the CoreCLR security system. Some of the needs for sandboxing that folks like SecondLife have (execution of untrusted code) can be found in our MonoSandbox page.
This is a great summary of how the security system works, from Shawn Farkas:
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
Posted on 08 Aug 2007