13.11 Manipulate Runtime Security Using Application Domain Evidence

Problem

You need to enforce an upper limit on the permissions available to all assemblies loaded into a particular application domain.

Solution

Configure security policy to grant the appropriate permissions based on the evidence you plan to assign to the application domain. As you create the application domain using the static method CreateDomain of the class System.AppDomain , provide a System.Security.Policy.Evidence collection containing the application domain's evidence objects. Load the assemblies whose permissions you want to limit into the application domain for execution.

Discussion

Just as the runtime assigns permissions to assemblies based on the evidence the assemblies present at load time, the runtime also assigns permissions to application domains based on their evidence. The runtime doesn't assign evidence to application domains the same way it assigns evidence to assemblies because there is nothing to base that evidence on. Instead, the code creating an application domain must assign evidence if required.

Note  

The runtime only uses the enterprise, machine, and user policy levels to calculate the permissions of an application domain; the security policies of existing application domains play no part. Recipe 13.12 discusses application domain security policy.

Application domains with no evidence are transparent to the runtime's code access security mechanisms. Those application domains assigned evidence have a grant set based on security policy and play an important role in the resolution of CAS security demands. When application execution crosses an application domain boundary, the runtime records the transition on the call stack. When a security demand causes a stack walk, the application domain transition records are processed the same as other stack records ”the runtime evaluates the grant set associated with the stack record to ensure it contains the demanded permissions. This means that the permissions of an application domain affect all code loaded into the application domain. In effect, the application domain establishes an upper limit on the capabilities of all code loaded into it.

An important example of using application domain evidence is Microsoft Internet Explorer. Internet Explorer creates an application domain for each site from which it downloads managed controls. All controls downloaded from a given site ”as well as the assemblies they load ”run in the same application domain. When Internet Explorer creates the application domain for a site, it assigns System.Security.Policy.Site evidence to the application domain. This ensures that if downloaded controls load an assembly (even from the local disk), the actions of the assembly are constrained by the permissions granted to the application domain based on the Site evidence and security policy.

Note  

Unless you explicitly assign evidence to an application domain as you create it, the application domain has no effect on security demands.

To assign evidence to an application domain, create an Evidence collection and add the required evidence objects to it using the Evidence.AddHost method. When you create the new application domain, pass the Evidence collection to one of the overloads of the static method CreateDomain . The runtime's usual policy resolution process will determine the grant set of the application domain.

The AppDomainEvidenceExample application shown here demonstrates how to assign evidence to an application domain. The example represents a scenario where the application loads code from a particular publisher into a publisher specific application domain. By assigning the application domain System.Security.Policy.Publisher evidence that represents the software publisher, the example limits the capabilities of the code loaded into the application domain. Using security policy, you can assign the publisher's code a maximum permission set commensurate with the level of trust you place in the publisher.

 using System; using System.Security.Policy; using System.Security.Cryptography.X509Certificates; public class AppDomainEvidenceExample {     public static void Main() {              // Create a new application domain for each publisher whose         // code the application will load. Pass the CreateAppDomain         // method the name of the company, and the name of a file         // containing the company's X.509v3 certificate.         AppDomain appDom1 = CreateAppDomain("Litware", "litware.cer");         AppDomain appDom2 = CreateAppDomain("Fabrikam", "fabrikam.cer");                  // Load code from the various publishers into the appropriate         // application domain for execution.              }     // A method to create a new application domain in which to load and run     // code from a specific publisher. The name argument specifies the name     // of the application domain. The certFile argument specifies the name      // of a file that contains an X.509v3 certificate for the software      // publisher whose code will be run in the new application domain.     private static AppDomain CreateAppDomain(string name, string certFile){                  // Create a new X509Certificate object from the X.509v3 certificate         // contained in the specified file.         X509Certificate cert =              X509Certificate.CreateFromCertFile(certFile);                  // Create new Publisher evidence from the X509Certificate object.         Publisher publisherEvidence = new Publisher(cert);         // Create a new Evidence collection.         Evidence evidence = new Evidence();         // Add the Publisher evidence to the Evidence collection.         evidence.AddHost(publisherEvidence);         // Create a new application domain with the Evidence         // collection containing the Publisher evidence         // and return the newly created application domain.         return AppDomain.CreateDomain(name, evidence);     } }