Yesterday we took a look at Whidbey's new Simple Sandboxing API.  At first glance this API does seem relatively simple, however when you start to look closer at the AppDomain that is created for your sandboxed code, there are a few surprising properties.

You might expect that under the covers this API is doing the grunt work of creating an AppDomain policy level which grants AllCode the specified permission set, and then has a code group for each strong name specified on the FullTrust list in order to provide those assemblies FullTrust.  However, this is not how the API works -- it actually uses an entirely different security model than the traditional policy level based one.  In fact, there is no AppDomain policy level in the sandboxed domain at all!  Instead the sandboxed domain simply keeps track of a set of FullTrust assemblies and a permission set to be granted to all other assemblies and the AppDomain itself.  No policy resolution will be done for assemblies loaded into this type of domain.

Why does Whidbey add this second AppDomain security model?  Aside from making it trivial for applications to sandbox untrusted code, it's also required for the ClickOnce security model.  ClickOnce allows an application to specify the exact set of permissions it should run under.  ClickOnce application authors test their applications with these permissions and expect to have exactly their requested permissions at runtime.  This AppDomain security model allows for that to occur.

Similarly, Visual Studio's debug-in-zone feature also requires an environment where the permissions it requests are exactly the permissions it gets -- if it were to debug your application with fewer privileges, debug-in-zone could lead to a lot of confusion when operations that are expected to pass start throwing SecurityExceptions.

Finally lets take a look at that evidence parameter to the CreateDomain API.  Since a sandboxed AppDomain does not resolve policy and always has a domain permission set equal to the grant set of the assemblies loaded into it, why does it need Evidence?  Technically the domain itself doesn't need that parameter, and it won't ever look at it directly.  However, the evidence is still stored on the AppDomain's Evidence property.  This means that other features which make decisions based upon AppDomain evidence (such as isolated storage), can still work with code executing in a simple sandboxed domain without modification.