Code Groups

Code Groups in .NET's Code Access Security (CAS)

Code Groups are a key component of Code Access Security (CAS) in the .NET Framework. They are used to organize and assign permissions to code based on its evidence. Code Groups, together with the security policy, define what actions or resources a particular piece of code can access, based on its evidence (such as its location, publisher, or strong name).

What Are Code Groups?

In CAS, Code Groups provide a way to categorize code and assign permissions to it based on specific evidence. A code group is a collection of assemblies or code that share a common set of characteristics. These characteristics are determined by the evidence associated with the code (such as URL, strong name, or publisher), and the code group can specify what permissions to grant to all the code it contains.

Key Concepts of Code Groups

1. Evidence-Based Membership:

   • A Code Group defines a set of code that shares certain evidence. Evidence is used to identify where the code comes from or what its identity is (e.g., its digital signature, the URL it came from, or its strong name).
   • Common types of evidence include:
     • URL Evidence: The location from which the code was downloaded.
     • Strong Name Evidence: The cryptographic signature associated with the code.
     • Publisher Evidence: The certificate that signed the code.
     • Site Evidence: The network site where the code is from (e.g., local intranet).

2. Permissions Associated with Code Groups:

   • Each Code Group is associated with a permission set. This permission set determines what the code in that group can or cannot do.
   • A permission set can include permissions such as the ability to access the file system, access the network, or execute code with reflection.
   • The permissions granted to code in a code group depend on the evidence that matches the code.

3. Code Group Hierarchy:

   • Code groups are hierarchical. This means that they can be nested within each other to create complex permission structures. For example, a top-level group could provide a broad set of permissions, while more specific subgroups could refine or limit these permissions.
   • Root Code Group: The root of the security policy is often called the "root" or "default" code group. It contains all code that doesn’t match any other group.
   • Child Code Groups: These are more specific groups that have a more restrictive set of permissions, often matching specific evidence (such as strong name or publisher).

4. Policy Levels and Code Groups:

   • Code groups are used in security policy levels to define what permissions different groups of code have. These levels can include:
     • Machine Policy: Applies to all code running on a machine.
     • User Policy: Applies to code running under a particular user account.
     • Application Policy: Applies to a specific application or assembly.
   • These policy levels use the code group concept to decide which permissions are applied based on the evidence provided.

5. Security Policy:

   • The security policy file defines the permissions associated with each code group. The security policy links code groups with permissions based on the evidence that the code presents.

How Code Groups Work

A code group works by matching evidence of the code against certain criteria defined in the code group, and then granting the associated permissions to the matching code. Here's how this process works:

1. Assembly Loads into CLR: When an assembly is loaded into the Common Language Runtime (CLR), the CLR collects the evidence of the assembly (such as its location, publisher, or strong name).

2. Matching Against Code Groups: The CLR then checks if the evidence of the assembly matches any defined code group. If the evidence matches, the assembly is considered a member of that code group.

3. Granting Permissions: Once the assembly has been placed into a code group, the permission set associated with that code group is granted to the code. The permissions could range from full trust to restricted access to specific resources.

4. Policy Level Application: The security policy defines the set of code groups and their corresponding permissions at different policy levels (machine, user, application). The CLR checks these policy levels and determines the final permission set based on where the code is running.

Example of Code Group Configuration

Here is an example of how code groups might be configured:

Scenario:

We want to create two code groups:

1. A LocalMachine code group that allows full access to code that comes from a trusted internal network.
2. A Internet code group that allows restricted access to code downloaded from the internet.

Steps to Configure Code Groups:

1. Machine Policy Code Group (Local): This code group grants full permissions to assemblies loaded from the Local Machine zone (i.e., trusted code running from the local computer).

   Example:

   Code Group: Local Machine Code Group
   Evidence: URL = "file:///*"
   Permissions: FullTrust (all permissions granted)
   

   In this case, code loaded from the local machine (file:///*) will be granted FullTrust permissions, meaning it can access system resources such as files, the network, etc.

2. Internet Code Group: This code group grants restricted permissions to code loaded from the Internet zone, such as code downloaded via HTTP.

   Example:

   Code Group: Internet Code Group
   Evidence: URL = "http://*"
   Permissions: ExecutionOnly (no file system access, no network access, etc.)
   

   In this case, code from an HTTP source will have very restricted permissions, such as ExecutionOnly, meaning it can execute code but cannot interact with the file system or network.

Code Group Structure in Security Policy

In a security policy file (e.g., machine.config), code groups can be nested and structured. A simple structure might look like this:

<securityPolicy>
    <policyLevels>
        <machine>
            <codeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust">
                <membershipConditions>
                    <urlMembershipCondition url="file:///*" />
                </membershipConditions>
            </codeGroup>
            <codeGroup class="UnionCodeGroup" version="1" PermissionSetName="ExecutionOnly">
                <membershipConditions>
                    <urlMembershipCondition url="http://*" />
                </membershipConditions>
            </codeGroup>
        </machine>
    </policyLevels>
</securityPolicy>

• UnionCodeGroup: This type of code group grants permissions if any of the membership conditions are satisfied.
• PermissionSetName: Defines the set of permissions granted to code in this group (e.g., FullTrust or ExecutionOnly).
• urlMembershipCondition: This condition matches code based on the URL or location from which it was loaded.

Code Group and Permissions Example in .NET Code

Here’s an example of how code groups can be used to specify permissions programmatically using attributes in .NET:

[PermissionSet(SecurityAction.Demand, Name = "FullTrust")]
public class TrustedCode
{
    public void ExecuteAction()
    {
        // This code will run only if the assembly has FullTrust permissions
        Console.WriteLine("Full Trust granted.");
    }
}

[PermissionSet(SecurityAction.Demand, Name = "ExecutionOnly")]
public class RestrictedCode
{
    public void ExecuteAction()
    {
        // This code will run with restricted permissions (e.g., no file access)
        Console.WriteLine("Restricted permissions granted.");
    }
}

In this example, the TrustedCode class demands FullTrust, meaning it can access all system resources, while RestrictedCode demands ExecutionOnly, limiting what it can do.

Important Points to Remember

• Code Groups Are Evidence-Based: The membership of a code group is determined by the evidence (e.g., URL, strong name, publisher) associated with the code.
• Code Group Hierarchy: Code groups can be nested within each other. More specific code groups can override the permissions granted by more general groups.
• Security Policy: The security policy is where code groups are defined, and it determines what permissions code in each group is granted.
• Deprecated in .NET Core/5+: CAS, including code groups, is deprecated in .NET Core and later versions. For modern .NET development, security is generally managed using other techniques like role-based access control, authentication, and authorization, rather than CAS.

Conclusion

Code Groups in .NET's Code Access Security model provide a way to categorize and manage code based on its identity and origin (evidence). By using code groups, developers can assign different permission sets to code depending on where it came from, what its identity is, and what actions it needs to perform. However, with the deprecation of CAS in .NET Core and newer versions, it's important to understand these concepts for working with legacy .NET Framework applications. For modern applications, newer security approaches are used to handle authentication, authorization, and resource access control.