In the .NET Framework version 4, the common language runtime (CLR) is moving away from providing security policy for computers. Microsoft is recommending the use of Windows Software Restriction Policies as a replacement for CLR security policy. The information in this topic applies to the .NET Framework version 3.5 and earlier; it does not apply to version 4.0 and later. For more information about this and other changes, see Security Changes in the .NET Framework 4.
Evidence is the information that the common language runtime uses to make decisions based on security policy. Evidence indicates to the runtime that code has a particular characteristic. Common forms of evidence include digital signatures and the location where code originates, but evidence can also be custom-designed to represent other information that is meaningful to the application. Both assemblies and application domains receive permission grants based on evidence.
The following table shows the common types of evidence that a host can present to the runtime.
The application's installation directory.
Cryptographic hash such as SHA1.
Software publisher signature; that is, the Authenticode signer of the code.
Site of origin, such as http://www.microsoft.com.
Cryptographically strong name of the assembly.
URL of origin.
Zone of origin, such as Internet Zone.
In addition to the forms of evidence listed in the table, application- or system-defined evidence can also be presented to the runtime. Trusted application domain hosts can present evidence about an assembly or application domain to the runtime. The runtime uses this information to evaluate enterprise, machine, and user policy (plus an application domain policy for assemblies, if set by the trusted application domain host) and return the set of permissions to grant to the assembly or application domain. If the trusted application domain host does not have permission to provide evidence, the assembly or application domain receives the permissions that have been granted to the host.
The runtime receives evidence about assemblies either from trusted application domain hosts or directly from the loader. Some evidence, such as where the code originates, usually comes from the trusted application domain host because only the host knows this information. Trusted application domain hosts can override evidence provided from the loader and can provide their own evidence.
Other evidence, such as an assembly's digital signature, is inherent in the code itself and can come from the loader or a trusted application domain host. Typically, the runtime validates each assembly's digital signature when the code is loaded. If the digital signature is valid, the trusted application domain host passes the signature information as evidence to the runtime's policy mechanism. In addition, an assembly or a trusted application domain host can provide custom evidence as a resource that is part of the assembly. Administrators and developers can define custom evidence and extend security policy to recognize and use it.
The runtime's policy mechanism uses the evidence from both the trusted application domain host and the assembly to determine a piece of code's membership in a code group.