A while back I gave some sample code to show how to setup a sandboxed AppDomain. This technique has worked since v1.0, and will continue to work with Whidbey. However, Whidbey also introduces a simple sandboxing API which eliminates the need for this boilerplate code, and makes setting up a sandboxed AppDomain trivial for your application.
This API is exposed as a new overload of AppDomain.CreateDomain:
AppDomain.CreateDomain( string friendlyName, Evidence securityInfo, AppDomainSetup info, PermissionSet grantSet, params StrongName fullTrustAssemblies);
The first three parameters should be familiar, since they're also used in other CreateDomain overloads. Where the simple sandboxing API gets interesting is with the last two parameters. These provide the permission set to grant to all assemblies in the domain, and a set of assemblies that should be treated as fully trusted.
These two parameters define the way that the sandboxed domain will trust assemblies. A sandboxed domain created with the simple sandboxing API has assemblies loaded with at most two grant sets. Either the assembly is fully trusted, or it is granted the permission set passed in via the grantSet parameter.
An assembly will be fully trusted if it meets one of two conditions, if neither of these conditions are met it receives grantSet:
We can easily construct a StrongName object for an assembly in the same way we created StrongNameMembershipCondition objects:
With that bit of code in place, it's now pretty trivial to create an AppDomain that grants, say only Execution permission to any assembly but the currently running one.
Clearly this API makes setting up a sandboxed domain much easier than the old method, which required you to setup an entire policy level, deal with various code groups, etc.
Next time we'll take a deeper look at the created domain, and discover what may be some surprising properties that it has.