Customizing the Microsoft .NET Framework Common Language Runtime

So far, I've described evidence as being associated solely with assemblies. Although this is clearly the most common scenario, it's also possible to associate evidence with an application domain. Application domain evidence is evaluated by CAS policy and a permission set is granted, just as it is done for assembly evidence. The CLR considers the permission set associated with the application domain while walking the stack to ensure that a particular permission demand is enforced. In essence, the application domain becomes another caller when viewed from the perspective of the CLR's stack walk. Figure 10-10 shows how the stack walk is affected by application domain evidence. In the figure, the assembly that issues the permission demand and all its descendents on the call stack are checked for the required permission. In addition, the permission set associated with the application domain is checked as well.

Application domain evidence can be used to grant a permission set that will restrict the operations that code running in the domain can perform. To see where this is useful, consider the case of an extensible application that is hosting code downloaded from a particular Web site. Let's say that such an application has a requirement that no code downloaded from the site will be granted more permissions than would be associated with the site's URL itself. This requirement can be enforced by associating evidence with the application domain that represents the site from which the code running in the domain came. Even if the downloaded code were granted more permission, because of a particular signature perhaps, the evidence and resulting permission set on the application domain will limit what that code can do.

Application domain evidence typically isn't used if you've already defined a CAS policy tree for your domain. The same restrictions you are enforcing through application domain evidence can also be specified using a policy tree. Application domain evidence is useful in scenarios such as the one described previously when your security requirements are straightforward enough to be expressed with application domain evidence without having to construct an entire policy tree.

Evidence is associated with an application domain using the securityInfo parameter either to AppDomain.CreateDomain or the implementation of CreateDomain provided by your application domain manager. (See Chapter 5 for more information about the role of an application domain manager in extensible applications.) For reference, here's the definition of CreateDomain from System.AppDomainManager:

public class AppDomainManager : MarshalByRefObject { public virtual AppDomain CreateDomain (string friendlyName, Evidence securityInfo, AppDomainSetup appDomainInfo) { } }

Listing 10-3 shows how to use application domain evidence. This example creates a type called TextWriter in a new application domain. TextWriter has a Write method that writes a text string to the specified file. Write accesses the file using the types from the System.IO namespace, which demand FileIOPermission to protect the file system properly. The application domain in which TextWriter is loaded is created with evidence representing the Internet zone. Permission to access the file system (FileIOPermission) is not granted to the Internet zone through default policy, so this application will fail with a security exception, even if the application is run from the local machine.

Listing 10-3. Appdomainevidence.cs

using System; using System.Security; using System.Security.Policy; using Utilities; namespace AppDomainEvidence { class Program { static void Main(string[] args) { // Create evidence representing the Internet zone. Evidence internetEvidence = new Evidence(); internetEvidence.AddHost(new Zone(SecurityZone.Internet)); // Create a new domain with the "Internet" evidence. AppDomain ad = AppDomain.CreateDomain("Custom Evidence Domain", internetEvidence); // Create an instance of the TextWriter class in the new // application domain. TextWriter w = (TextWriter) ad.CreateInstanceAndUnwrap( "Utilities","Utilities.TextWriter"); // Call a method on TextWriter that writes text to a file. // This method demands FileIOPermission. This operation // will fail with a security exception because callers in // the Internet zone are not granted FileIOPermission through // default CAS policy. w.Write("file.txt", "Hello World!"); } } }