Evidence Explained

for RuBoard

Evidence provides the basic building blocks for how code access security can work on .NET Framework code. An example of evidence about code is its SHA1 hash value.

This value is a cryptographically strong piece of information that is unique for different pieces of code. Thus, it is useful in providing identification.

TIP

For more information on cryptographic hash values, see Chapter 30, "Using Cryptography with the .NET Framework: The Basics."

There are two key points to remember about evidence:

• Evidence applies to executing code itself, not the user who is executing the code.

• Evidence is applied to the granularity of assemblies and application domains.

TIP

Application domains will be mentioned several times in this book. They are also referred to as app domains.

Evidence Applies to Executing Code

Evidence is a collection of information that is gathered about executing code, regardless of who is running it. Figure 5.1 shows an example of this. Given two users, Alice and Bob, running assembly X, the security engine (that is, the part of the CLR that is wholly charged with enforcing security) should provide the exact same evidence regarding X (with one possible exception, its security zone, which will be covered in the final section in this chapter). When Alice runs X, its SHA1 hash value doesn't differ from when Bob runs it.

Figure 5.1. Evidence calculated for the same application when run by different users.

In a way, you can look at different .NET applications as different users, where evidence is the set of credentials for an application. This analogy doesn't work for all pieces of .NET Framework security, but it will help you understand the role of evidence. Evidence is how .NET Framework security differentiates one piece of code from another.

Another important piece of information regarding evidence is that it only applies to code that is executing. The .NET Framework will not precompute or cache evidence for code that is not executing. Evidence is dynamically calculated and applied when code is running. In fact, some evidence is impossible to know before code executes. For example, the URL of origin for an executing application is impossible to know beforehand since that application may exist at many different locations or be referenced by different URLs that point to the same location.

Evidence Is Applied to Assemblies and App Domains

So far, I have made the assertion that evidence is applied to running code. However, "running code" is a general concept. To be more specific about this concept, we have to understand the building blocks of a process in the .NET Framework.

In the .NET Framework, app domains are sort of like mini-processes themselves . They are the repository for loaded assemblies, and they represent a logical barrier to separate execution of code. Every .NET process contains at least one app domain, and every app domain will have assemblies loaded into it. Evidence is applied to both assemblies and app domains, so every different assembly and app domain will have individual identities.

Assemblies

An assembly is a well-defined entity in the .NET Framework. It is the primary mechanism for dividing compiled code to be loaded at a later time. It is usually, though not necessarily , a single file that contains a library or an executable file (for example, a DLL file or an EXE file). However, an assembly may contain multiple files, in which case, the primary file in the assembly is called the manifest.

In the .NET Framework, an assembly is referenced by using the System.Reflection.Assembly class. Assemblies can be loaded directly from the file system or the Global Assembly Cache. Assemblies loaded from the global cache are shared across all applications using the .NET Framework. Assemblies provided by the .NET Framework SDK will generally be located in the global cache, while assemblies for individual applications will generally be located in the individual application directories. This is similar to what Windows does with DLLs and the %windir%\system32 directory. System libraries, such as the C runtime library, are placed there for all applications to use. However, the global cache is different in that it can simultaneously store several different versions of the same assembly. For more information on the Global Assembly Cache, see the .NET Framework SDK.

Because evidence is not precomputed by the .NET Framework, you cannot know exactly what evidence will be associated with an assembly you write. However, you can examine the evidence associated with an assembly at the time of execution by using the System.Reflection.Assembly.Evidence property. To obtain the evidence of an executing assembly, simply utilize the following code:

 System.Security.Policy.Evidence ev = System.Reflection.Assembly. GetExecutingAssembly().  Evidence; 

App Domains

Essentially, application domains provide in-process isolation of executing code. All .NET Framework code must run in some app domain. While it isn't obvious by running a simple "Hello World" application, a default app domain is created for every .NET Framework process. If no other app domains are created, all code runs in the default domain.

NOTE

The same assembly can be loaded into multiple app domains at the same time. When this happens, the compiled code in memory can be shared to reduce the working set. However, static data is not shared between app domains. If it were shared, this would mean a breakdown in the isolation that app domains are meant to provide.

App domains use the System.AppDomain class to represent them to managed code. The AppDomain class has an identical property as the Assembly class for handling evidence. To obtain evidence on the current AppDomain , you can use the following code:

 System.Security.Policy.Evidence ev = System.AppDomain.CurrentDomain.Evidence; 

App domains are particularly valuable for the following tasks :

• Loading assemblies that you want to unload at a later time. (In fact, the only way to unload an assembly is to unload the app domain containing that assembly.)

• Providing fewer rights than provided by default policy to less-trusted assemblies. (App domain policy is discussed in Chapter 8, "Membership Conditions, Code Groups, and Policy Levels: The Brick and Mortar of Security Policy.")

• Running several tasks that should be isolated from each other without using multiple processes.

for RuBoard