Evidence

Evidence in Code Access Security (CAS)

Evidence is a critical concept in Code Access Security (CAS) in .NET, used to determine the identity of the code that is being executed. The role of evidence is to classify and categorize the code based on its origin, ensuring that only trusted code can access resources and perform sensitive operations. When an assembly is loaded into the .NET runtime, it presents evidence that helps the Common Language Runtime (CLR) decide which permissions should be granted to that code.

1. What is Evidence?

In the context of CAS, evidence is the information about an assembly or piece of code that is used to determine its trustworthiness. Evidence can include various properties, such as:

• The URL where the code is loaded from (e.g., a local file or a web server).
• The strong name of the code, which is a cryptographic identity.
• The digital signature or certificate of the publisher.
• The site from which the code originates (such as a trusted intranet site).
• The hash code of the assembly.

The .NET runtime evaluates this evidence to assign security permissions to the code, and the code group (a collection of similar code) that the code belongs to determines what permissions it has.

2. Types of Evidence

There are several types of evidence that can be used to identify and classify assemblies. Some of the key evidence types include:

2.1. URL Evidence

• URL Evidence describes the location from which the assembly was loaded. This can be a local file path, a network location, or an HTTP/HTTPS URL.
• For example, code loaded from http://www.example.com/assembly.dll could be classified differently from code loaded from the local file system (file://C:/ProgramFiles/assembly.dll).
• Example:

  UrlMembershipCondition urlCondition = new UrlMembershipCondition("http://www.example.com/*");
  

2.2. Strong Name Evidence

• Strong Name Evidence involves the unique identity of an assembly, based on a cryptographic signature. An assembly with a strong name is signed with a public/private key pair, and its identity is based on the public key, version, and other assembly metadata.
• This type of evidence is used to ensure that the assembly has not been tampered with and comes from a trusted source.
• Example:

  StrongNameMembershipCondition strongNameCondition = new StrongNameMembershipCondition("PublicKey", "AssemblyName", "Version");
  

2.3. Publisher Evidence

• Publisher Evidence is used to identify the publisher or the certificate that signed the assembly. If the code is digitally signed with a trusted certificate, this evidence can help the system determine that the code is from a trusted source.
• This is particularly important in environments where code is distributed via the internet (e.g., downloaded assemblies).
• Example:

  PublisherMembershipCondition publisherCondition = new PublisherMembershipCondition(new X509Certificate("certificate_path"));
  

2.4. Site Evidence

• Site Evidence identifies the site or domain from which the assembly originates. This is useful when determining whether code from a trusted domain should be granted specific permissions.
• For example, assemblies loaded from an intranet site might be given more permissions than code loaded from a non-trusted external site.
• Example:

  SiteMembershipCondition siteCondition = new SiteMembershipCondition("www.example.com");
  

2.5. Hash Evidence

• Hash Evidence is used when the hash of an assembly is calculated and compared to a known hash value. This is useful for verifying that the assembly has not been altered after it was originally signed or distributed.

3. How Evidence is Used in CAS

In CAS, evidence is associated with code groups and is used to determine what permissions an assembly should have. The Common Language Runtime (CLR) evaluates the evidence presented by an assembly and uses it to match the assembly to a code group that defines the permissions it should receive.

4. Process of Evidence Evaluation

When the CLR loads an assembly, it performs the following steps:

1. Collect Evidence: The CLR collects the evidence from the assembly. This includes things like its URL, digital signature, publisher certificate, and strong name.

2. Match Against Code Groups: The CLR then checks the security policy to see if any code groups match the evidence of the assembly. Code groups define what evidence is required to belong to them, and the CLR checks whether the assembly's evidence satisfies the membership conditions for any code group.

3. Grant Permissions: Once the evidence matches a code group, the CLR grants the permissions defined in that code group's associated permission set. If there is no matching code group, the assembly is treated as potentially untrusted and is granted minimal permissions (or no permissions).

4. Permission Checking: The CLR checks whether the code is allowed to perform actions, like reading a file or making a network request, based on the permissions granted by the code group.

5. Example of Using Evidence in Code

Here is an example that demonstrates how evidence can be used to grant permissions:

using System;
using System.Security;
using System.Security.Policy;

class EvidenceExample
{
    public static void Main()
    {
        // Define evidence based on the URL from which the code is loaded
        UrlMembershipCondition urlEvidence = new UrlMembershipCondition("file:///*");

        // Define evidence based on the strong name of the assembly
        StrongNameMembershipCondition strongNameEvidence = new StrongNameMembershipCondition(
            new StrongNamePublicKeyBlob(new byte[] { /* public key bytes */ }),
            "MyAssembly", 
            new Version("1.0.0.0"));

        // Combine evidence for policy evaluation
        Evidence evidence = new Evidence();
        evidence.Add(urlEvidence);
        evidence.Add(strongNameEvidence);

        // Perform a security demand
        try
        {
            new PermissionSet(PermissionState.None).Demand();
            Console.WriteLine("Permission granted!");
        }
        catch (SecurityException ex)
        {
            Console.WriteLine("Security Exception: " + ex.Message);
        }
    }
}

In this example:

• UrlMembershipCondition checks if the code is loaded from the local file system (file:///*).
• StrongNameMembershipCondition checks if the assembly has a specific strong name.

Based on the evidence, the CLR will assign the appropriate permissions to the assembly.

6. Evidence Types and Security Policy

The security policy files (like machine.config, user.config, or app.config) map evidence types to code groups, each of which defines a set of permissions for matching assemblies. The policy settings ensure that code can only access the resources that are allowed based on its evidence.

Example of Policy File Configuration

In the security policy files, you might have entries like:

<codeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust">
    <membershipConditions>
        <urlMembershipCondition url="file:///*" />
    </membershipConditions>
</codeGroup>
<codeGroup class="UnionCodeGroup" version="1" PermissionSetName="ExecutionOnly">
    <membershipConditions>
        <strongNameMembershipCondition publicKey="publicKeyBytes" />
    </membershipConditions>
</codeGroup>

• First Code Group: Grants full permissions to code loaded from the local file system (file:///*).
• Second Code Group: Grants restricted permissions (like execution only) to assemblies with a specific strong name.

7. Conclusion

Evidence in .NET's Code Access Security (CAS) is essential for classifying code and determining its trustworthiness. The CLR uses evidence such as the location, strong name, digital signature, and other factors to determine what permissions should be granted to an assembly. By combining different types of evidence, developers can define granular security policies to control access to system resources. This security mechanism allows for fine-grained control over the permissions granted to assemblies based on where they came from and what their identity is.