Code Access Security and the .NET Framework

The security mechanisms discussed so far in this chapter all validate users by gathering and checking user credentials against trusted credential authorities. Just as there are users who might damage or compromise data, either intentionally or by accident , there are malicious or poorly written code fragments that, if executed unchecked, could violate the security of your portal site.

These code fragments can come from many sources: Internet pages, email messages, downloads by users, and so on. When Windows executes the code, in most cases it trusts the code implicitly (many script-based languages, like JavaScript and VBScript, have built-in restrictions on what they can do that limits their access to underlying operating system resources). Imagine that there is a middle- tier component on your site that contains the DeleteFile method. When executed properly within the context of your application, this method is responsible for cleaning temp files. If a malicious user were to gain control of the assembly containing this method, DeleteFile could be executed and some vital files on your servers could be destroyed . Without Code Access Security (CAS), your only protection lies in the restrictions on the user account under which the code executes. Because in many cases this would be the Local System account, the protection is ephemeral.

To enable protection from malicious code running on your servers and from legitimate code performing undesired actions (as the result of bugs in the code), Microsoft has created an additional security mechanism in .NET called CAS. It allows you to explicitly describe what the code executing on your server can do based on the code origination and some other code properties.

User-based security and code-based security complement each other in securing sites. When determining whether to grant or deny resource access, both security mechanisms run their permission checks, granting access only when both have succeeded.

This section briefly outlines the main ideas and usage patterns of CAS. At the foundation of CAS is the idea of analyzing the source of the code and assigning different trust levels based on the code origination. The code installed by your network administrator would have a higher trust level than the code downloaded from a web site. Because you can have code from disparate sources executing together within the context of your application, it is possible for code with a lower trust level to execute code with a higher trust level and acquire the execution results (returned data or system resources) from the higher trust level code, thus breaking the trust boundary. To prevent this from happening, CAS scans the call stack and tries to match the permissions granted to each caller in the stack to the requested set of permissions. If it encounters a caller with insufficient permissions, it throws a security exception and the resource is not accessed.

With this foundation, we are ready to discuss the two most important concepts of the CAS mechanism:

• Code evidence

• Code permissions

Code Evidence

The unit of code as it is analyzed by CAS and the .NET Framework is an assembly. CAS collects information about an assembly, which is known as evidence. Different assemblies carry different sets of evidence data. Generally, the following data is collected together as assembly evidence:

• URL of assembly origin

• Site of assembly origin

• Application root folder

• Cryptographic value (hash) associated with the assembly

• Authenticode signature of the assembly created by its author

• Strong name of the assembly (strong names provide a unique identity for an assembly and consist of the assembly text name, version number, culture information, public key, and a digital signature)

CAS assigns various weight parameters to different evidence values. The authenticode value, for example, is more important than the site name. Evidence is calculated dynamically when the assembly executes, and it is not cached.

Code Permissions

While code evidence allows CAS to authenticate running code (assembly), code permissions are employed in the implementation of the authorization mechanism. CAS authenticates an assembly using assembly evidence and authorizes resource requests by using code permissions. Permissions define exactly what your assembly can and cannot do.

The System.Security.Permissions namespace contains a fairly granular set of classes that control permission sets for various areas. Some of the classes include:

• FileIOPermission. Controls the ability to access files and folders.

• UIPermission. Controls the permissions related to user interfaces and the Clipboard.

• RegistryPermission. Controls the ability to access registry variables .

Once the evidence set is created from the executing assembly, CAS can look at the hierarchical set of existing security policies and apply the evidence. When this process is complete, CAS assigns the resultant access rights to the assembly.

To administratively configure CAS, use the .NET configuration Microsoft Management Console (MMC) plug-in. To start MMC:

1. Select Run from the Start menu and enter MMC to open a blank MMC console window.
   
   
2. Select Add/Remove Snap-in from the File menu.
   
   
3. In the Add Snap-in dialog box, click Add .
   
   
4. Select the .NET Configuration snap-in.
   
   

There are three different sets of security policies installed with the framework (enterprise, machine, and user) and several built-in permissions (FullTrust, SkipVerification, and so on). Both policy sets and permissions can be created or modified by administrators or through code. Figure 6.10 shows the MMC CAS snap-in displaying the CAS settings for the local machine.

Figure 6.10. MMC Snap-in for CAS Configuration

In addition to permissions determined for your assembly when it executes based on configured policy set and assembly evidence, you can also demand permissions programmatically in code. There are two kinds of permission demands, declarative and imperative. The names refer to the way you try to acquire permissions in code. With a declarative permission demand, you use standard code attributes (stored in the metadata of your assembly); with an imperative demand, you use classes from the System.Security.Permissions namespace.

Listing 6.1 demonstrates both concepts with a simple DeleteFile function.

Listing 6.1. Using Permission Demands in Code

 ' Import the Permissions namespace Imports System.Security.Permissions ' Example of using Declarative permission demand <FileIOPermission(SecurityAction.Demand)> Public Function DeleteFile(byval strFileToDelete as string) as boolean   try    System.IO.File.Delete(strFileToDelete) catch SecException as SecurityException    ... code to process exception thrown by CAS   catch GeneralException as Exception    ... code to process generic exception   end try End Sub ' Example of using Imperative permission demand Public Function DeleteFile(byval strFileToDelete as string) as boolean   try    Dim DeletePerm as New FileIOPermission(FileIOPermissionAccess. _    AllAccess, _                       strFileToDelete)    DeletePerm.Demand()    System.IO.File.Delete(strFileToDelete)   catch SecException as SecurityException    ... code to process exception thrown by CAS   catch GeneralException as Exception    ... code to process generic exception   end try End Sub 

For a detailed discussion of CAS, refer to MSDN at msdn.microsoft.com/library/en-us/cpguide/html/cpconcodeaccesssecurity.asp.