Code Access Security Explained

To use code access security effectively, you need to know the basics such as the terminology and how policy is evaluated. For further background information about code access security, see the "Additional Resources" section at the end of this chapter. If you are already familiar with code access security, you may want to skip this section and go to the "APTCA" ( AllowPartiallyTrustedCallersAttribute ) section later in this chapter.

Code access security consists of the following elements:

• Code

• Evidence

• Permissions

• Policy

• Code groups

Code

All managed code is subject to code access security. When an assembly is loaded, it is granted a set of code access permissions that determines what resource types it can access and what types of privileged operations it can perform. The Microsoft .NET Framework security system uses evidence to authenticate (identify) code to grant permissions.

Note  

An assembly is the unit of configuration and trust for code access security. All code in the same assembly receives the same permission grant and is therefore equally trusted.

Evidence

Evidence is used by the .NET Framework security system to identify assemblies. Code access security policy uses evidence to help grant the right permissions to the right assembly. Location- related evidence includes:

• URL . The URL that the assembly was obtained from. This is the codebase URL in its raw form, for example, http:// webserver /vdir/bin/assembly.dll or file://C:/directory1/directory2/assembly.dll.

• Site . The site the assembly was obtained from, for example, http://webserver. The site is derived from the codebase URL.

• Application directory . The base directory for the running application.

• Zone . The zone the assembly was obtained from, for example, LocalIntranet or Internet. The zone is also derived from the codebase URL.

Author-related evidence includes:

• Strong name . This applies to assemblies with a strong name. Strong names are one way to digitally sign an assembly using a private key.

• Publisher . The Authenticode signature; based on the X.509 certificate used to sign code, representing the development organization.

  Important  

  Publisher evidence (the Authenticode signature) is ignored by the ASP.NET host and therefore cannot be used to configure code access security policy for server-side Web applications. This evidence is primarily used by the Internet Explorer host.

• Hash . The assembly hash is based on the overall content of the assembly and allows you to detect a particular compilation of a piece of code, independent of version number. This is useful for detecting when third party assemblies change (without an updated version number) and you have not tested and authorized their use for your build.

Permissions

Permissions represent the rights for code to access a secured resource or perform a privileged operation. The .NET Framework provides code access permissions and code identity permissions. Code access permissions encapsulate the ability to access a particular resource or perform a privileged operation. Code identity permissions are used to restrict access to code, based on an aspect of the calling code's identity such as its strong name.

Your code is granted permissions by code access security policy that is configured by the administrator. An assembly can also affect the set of permissions that it is ultimately granted by using permission requests. Together, code access security policy and permission requests determine what your code can do. For example, code must be granted the FileIOPermission to access the file system, and code must be granted the RegistryPermission to access the registry. For more information about permission requests, see the "Requesting Permissions" section later in this chapter.

Note  

Permission sets are used to group permissions together to ease administration.

Restricted and Unrestricted Permissions

Permissions can be restricted or unrestricted . For example, in its unrestricted state, the FileIOPermission allows code to read or write to any part of the file system. In a restricted state, it might allow code to read files only from a specific directory.

Demands

If you use a class from the .NET Framework class library to access a resource or perform another privileged operation, the class issues a permission demand to ensure that your code, and any code that calls your code, is authorized to access the resource. A permission demand causes the runtime to walk back up through the call stack (stack frame by stack frame), examining the permissions of each caller in the stack. If any caller is found not to have the required permission, a SecurityException is thrown.

Link Demands

A link demand does not perform a full stack walk and only checks the immediate caller, one stack frame further back in the call stack. As a result, there are additional security risks associated with using link demands. You need to be particularly sensitive to luring attacks.

Note  

With a luring attack, malicious code accesses the resources and operations that are exposed by your assembly, by calling your code through a trusted intermediary assembly.

For more information about how to use link demands correctly, see the" Link Demands" section later in this chapter.

Assert, Deny, and PermitOnly Methods

Code access permission classes support the Assert , Deny , and PermitOnly methods. You can use these methods to alter the behavior of a permission demand stack walk. They are referred to as stack walk modifiers .

A call to the Assert method causes the stack walk for a matching permission to stop at the site of the Assert call. This is most often used to sandbox privileged code. For more information, see the "Assert and RevertAssert" section later in this chapter.

A call to the Deny method fails any stack walk that reaches it with a matching permission. If you call some non-trusted code, you can use the Deny method to constrain the capabilities of the code that you call.

A call to the PermitOnly method fails any unmatching stack walk. Like the Deny method, it tends to be used infrequently but it can be used to constrain the actions of some non-trusted code that you may call.

Policy

Code access security policy is configured by administrators and it determines the permissions granted to assemblies. Policy can be established at four levels:

• Enterprise . Used to apply Enterprise-wide policy.

• Machine . Used to apply machine-level policy.

• User . Used to apply per user policy.

• Application Domain . Used to configure the application domain into which an assembly is loaded.

  ASP.NET implements application domain policy to allow you to configure code access security policy for Web applications and Web services. For more information about ASP.NET application domain policy, see Chapter 9, "Using Code Access Security with ASP.NET."

Policy settings are maintained in XML configuration files. The first three levels of policy (Enterprise, Machine, and User) can be configured by using the .NET Framework Configuration tool, which is located in the Administrative Tools program group or the Caspol.exe command line utility. ASP.NET application domain level policy must currently be edited with a text or XML-based editor.

For more information about policy files and locations, see Chapter 19, "Securing Your ASP.NET Application and Web Services."

Code Groups

Each policy file contains a hierarchical collection of code groups. Code groups are used to assign permissions to assemblies. A code group consists of two elements:

• A membership condition . This is based on evidence, for example, an assembly's zone or its strong name.

• A permission set . The permissions contained in the permission set are granted to assemblies whose evidence matches the membership condition.

How Does It Work?

Figure 8.1 shows a simplified overview of code access security.

Figure 8.1: Code access security ” a simplified view

The steps shown in Figure 8.1 are summarized below.

1. An assembly is loaded.

   This operation is performed by an application domain host. On a Web server loading a Web application assembly, this is the ASP.NET host.

2. Evidence is gathered from the assembly and presented by the host.

3. Evidence is evaluated against the defined security policy.

4. The output from security policy evaluation is one or more named permission sets that define the permission grant for the assembly.

   Note  

   An assembly can include permission requests, which can further reduce the permission grant.

5. Code within the assembly demands an appropriate permission prior to accessing a restricted resource or performing a privileged operation.

   All of the .NET Framework base classes that access resources or perform privileged operations contain the appropriate permission demands. For example, the FileStream class demands the FileIOPermission , the Registry class demands the RegistryPermission , and so on.

6. If the assembly (and its callers ) have been granted the demanded permission, the operation is allowed to proceed. Otherwise, a security exception is generated.

How Is Policy Evaluated?

When evidence is run through the policy engine, the output is a permission set that defines the set of permissions granted to an assembly. The policy grant is calculated at each level in the policy hierarchy: Enterprise, Machine, User, and Application Domain. The policy grant resulting from each level is then combined using an intersection operation to yield the final policy grant. An intersection is used to ensure that policy lower down in the hierarchy cannot add permissions that were not granted by a higher level. This prevents an individual user or application domain from granting additional permissions that are not granted by the Enterprise administrator.

Figure 8.2 shows how the intersection operation means that the resulting permission grant is determined by all levels of policy in the policy hierarchy.

Figure 8.2: Policy intersection across policy levels

In Figure 8.2, you can see that the intersection operation ensures that only those permissions granted by each level form part of the final permission grant.

How Do Permission Requests Affect the Policy Grant?

You can add security attributes to your assembly to specify its permission requirements. You can specify the minimal set of permissions that your assembly must be granted in order to run. These do not affect the permission grant. You can also specify the optional permissions your assembly could make use of but does not absolutely require, and what permissions you want to refuse . Refused permissions are those permissions you want to ensure your assembly never has, even if they are granted by security policy.

If you request optional permissions, the combined optional and minimal permissions are intersected with the policy grant, to further reduce it. Then, any specifically refused permissions are taken away from the policy grant. This is summarized by the following formula where PG is the policy grant from administrator defined security policy and P _min , P _opt , and P _refused are permission requests added to the assembly by the developer.

Resulting Permission Grant = (PG (P _min ˆ P _opt )) “ Prefused

For more information about how to use permission requests, their implications, and when to use them, see the "Requesting Permissions" section later in this chapter.

Policy Evaluation at a Policy Level

An individual policy file at each specific level consists of a hierarchical arrangement of code groups. These code groups include membership conditions that are used to determine which assemblies they apply to, and permission sets that are used to determine the permissions that should be granted to matching assemblies. A hierarchical structure enables multiple permission sets to be assigned to an assembly, and it allows security policy to support simple AND and OR logic. For example, consider the sample security policy shown in Figure 8.3.

Figure 8.3: Hierarchical code groups at a single policy level

Note  

The All Code code group is a special code group that matches all assemblies. It forms the root of security policy and in itself grants no permissions, because it is associated with the permission set named Nothing .

Consider the granted permissions based on the security policy shown in Figure 8.3.

• Any assembly originating from the My _ Computer_Zone (any locally installed assembly), is granted the permissions defined by the FullTrust permission set. This is a built-in permission set defined when the .NET Framework is installed and represents the unrestricted set of all permissions.

• Assemblies authored by Company1 and originating from the intranet zone are granted the permissions defined by the built-in LocalIntranet_Zone permission set and the custom Comp1PSet permission set.

• Assemblies authored by Company2 are granted permissions defined by the custom Comp2PSet permission set.

• Any assembly downloaded from a.b.c.com is granted permissions defined by the custom ABCPSet permission set.

  Note  

  If the membership condition for a particular code group is not satisfied, none of its children are evaluated.

Exclusive and Level Final Code Groups

Policy hierarchy processing and traversal can be fine- tuned using a couple of attributes specified at the code group level, both of which can be set through the .NET Framework Configuration Tool. These are:

• Exclusive

  This indicates that no other sibling code groups should be combined with this code group. You mark a code group as exclusive by selecting This policy level will only have the permissions from the permission set associated with this code group in the .NET Framework Configuration Tool.

• Level Final

  This indicates that any lower level policies should be ignored. You mark a code group as Level Final by selecting Policy levels below this level will not be evaluated in the .NET Framework Configuration Tool. For example, if a matching code group in the machine policy is marked Level Final , policy settings from the user policy file is ignored.

  Note  

  The application domain level policy, for example, ASP.NET policy for server-side Web applications, is always evaluated regardless of the level final setting.