SECURITY

Evidence Explained in .NET Security

9/14/2010 5:34:18 PM

Some types of evidence are inherent in the structure and content of an assembly, such as the assembly strong name, the hash value of the assembly's content, or the publisher certificate used to sign the assembly. Other types of evidence are determined at runtime, based on characteristics such as the web site or URL from where the assembly is loaded.

The combined set of evidence establishes an identity for the assembly. When the runtime loads an assembly, it compares the assembly's identity with the rules defined in the security policy to determine the permissions to grant to the assembly, called the grant set. The grant set defines the operations that the code contained in the assembly can perform.

It is important to understand that the same assembly can have very different identities (and hence permissions) based on runtime evidence. If you run an assembly from an Internet site, its evidence will be different than if you first download the assembly to your hard disk and run it locally. We demonstrate this in "Viewing Evidence" later in this chapter.


Application domains also have an identity based on evidence. As with assemblies, the runtime uses evidence and security policy to determine the application domain's grant set. The grant set of an application domain has an important but indirect effect on the operations and resources accessible to all of the assemblies running in it.

Sources and Types of Evidence

There are two types of evidence: host evidence and assembly evidence. When the runtime loads an assembly, it instantiates objects to represent each piece of evidence and associates the set of objects with the assembly as host evidence. An assembly can contain additional evidence, embedded at build time. As the runtime loads the assembly, it extracts this additional evidence and associates it with the assembly as assembly evidence.

The purpose of both types of evidence is to give the assembly an identity, which the runtime uses to determine the permissions to grant to it. However, the default behavior of the .NET runtime is to ignore assembly evidence; only through the implementation of CAS extensions can you enable assembly evidence to drive the policy resolution process.

Figure 1 shows the key characteristics found in an assembly characteristics and how the runtime uses each to create either host and assembly evidence. The following two sections discuss the nature and purpose of host and assembly evidence in more detail.

Figure 1. Sources and destinations of evidence

1. Host evidence

The host, in conjunction with the assembly loader component of the CLR, provides the host evidence for an assembly; the host could be one of the standard .NET runtime hosts (command shell, Internet Explorer, or ASP.NET), a custom runtime host, or a trusted piece of managed code that explicitly loads an assembly at runtime. The assembly loader provides a default set of evidence, but evidence provided by the host takes precedence if it conflicts with the default evidence.

A host's ability to provide and override evidence is extremely powerful; essentially the host can give any identity to an assembly. With this ability, malicious code could manipulate the evidence of the assemblies it loads in order to make the runtime assign them artificially high levels of trust. Therefore, .NET protects the ability to provide host evidence with the ControlEvidence permission—an element of the System.Security.Permissions.SecurityPermission permission.

A class in the System.Security.Policy namespace represents each of the seven standard types of host evidence that the .NET Framework supports. Not every loaded assembly has all types of evidence; an assembly's evidence depends on both its characteristics and the characteristics of the host that loaded it. Table 1 lists the standard evidence types.

Table 1. Standard .NET evidence types
Evidence class Description
ApplicationDirectory Represents the root directory of an application. ApplicationDirectory is used in conjunction with Url evidence during policy resolution.
Hash Represents the hash value of the assembly contents. The runtime provides Hash evidence for all assemblies.
Publisher Represents the Authenticode X509 digital certificate used to sign the assembly. The runtime only provides Publisher evidence for assemblies signed with a digital certificate.
Site Represents the host portion of the URL from which the assembly was loaded. The runtime provides Site evidence for all assemblies loaded from non-file:// protocol URLs.
StrongName Represents the strong name of the assembly. The runtime provides StrongName evidence only when the assembly has a strong name.
Url Represents the URL from which the assembly was loaded. The runtime provides Url evidence for all assemblies. For assemblies loaded from the local disk, the URL protocol will be file:// whereas assemblies downloaded from a web site have the protocol http:// or https://.
Zone Represents the Internet Explorer security zone from where the assembly was loaded. The runtime provides Zone evidence for all assemblies.

In addition to the classes listed in Table 6-1, custom hosts and managed code that dynamically load assemblies can provide any type of object as host evidence; but unless you extend the policy resolution mechanism to understand the custom evidence classes, the runtime will ignore them.

2. Assembly evidence

The purpose of assembly evidence is to allow you to serialize custom evidence objects and embed them into your assembly at build time. When the runtime loads your assembly, it extracts and deserializes the embedded objects and assigns them to your assembly as assembly evidence.

You are free to use assembly evidence to represent any additional assembly characteristics you require; the example we use later in "Extending the .NET Framework" identifies the programmer who created the assembly.

You can use any type of serializable object as assembly evidence. However, you cannot use any of the standard evidence types listed in Table 1; the runtime will ignore them when it loads the assembly.


As we mentioned earlier, the default configuration of the .NET Framework is to ignore assembly evidence. With some customization of CAS, assembly evidence can affect the resolution of code-access permissions in the same way as the standard evidence classes. However, the runtime never grants identity permissions to your assembly based on assembly evidence; only host evidence results in the granting of identity permissions. This does limit the usefulness of assembly evidence, but is necessary to stop malicious code from manipulating CAS and granting itself identity permissions in an attempt to increase its level of trust.

Other  
 
Top 10
Review : Sigma 24mm f/1.4 DG HSM Art
Review : Canon EF11-24mm f/4L USM
Review : Creative Sound Blaster Roar 2
Review : Philips Fidelio M2L
Review : Alienware 17 - Dell's Alienware laptops
Review Smartwatch : Wellograph
Review : Xiaomi Redmi 2
Extending LINQ to Objects : Writing a Single Element Operator (part 2) - Building the RandomElement Operator
Extending LINQ to Objects : Writing a Single Element Operator (part 1) - Building Our Own Last Operator
3 Tips for Maintaining Your Cell Phone Battery (part 2) - Discharge Smart, Use Smart
REVIEW
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
VIDEO TUTORIAL
- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
Popular Tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8