Code Access Security with Microsoft .NET Framework

CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Evidence-Based Security

This installment of .NET Nuts & Bolts is part one of a two-part series exploring code access security and how it is controlled by the Microsoft .NET Framework. The Microsoft .NET Framework includes a number of security features that assist you in developing secure applications. The security system, which is a fundamental part of the common language runtime (CLR), controls execution of .NET code. It includes handy features such as the following:

• Type safety enforcement, which eliminates the potential for buffer overruns
• Arithmetic error trapping, which detects the potential for underflows and overflows

In addition, the .NET Framework provides the concept of evidence-based security. Evidence-based security works on top of the security provided by the operating system. For example, it works on top of Win32 security but is not a replacement for Win32 security. While Win32 is based on the user, the evidence-based security is based on the assembly. It gathers and presents information (or evidence) about the assembly to the security system, which then determines whether or not to allow the code to execute. For example, if code tries to read a file during execution, the security system verifies that the assembly has the required permissions and either grants access or throws a SecurityException.

Evidence about an assembly can be controlled and influenced through things like strongly named assemblies, Authenticode signatures, or other custom information. Evidence is mapped to permissions through security policies, which rely on permission sets, code groups, and policy levels (enterprise, machine, and user settings) to achieve the mapping. Policies can be deployed throughout your organization through the Active Directory, but this discussion doesn’t get into the specifics of that.

Code Group Example

Rather than explaining all of the concepts up front, this tutorial just dives right into an example and explains the concepts along the way. The example is a sample Windows Forms application that demonstrates the use of permission sets and code groups. The example code will try to read the contents of a file and display a message indicating success or failure. A strong name for the assembly will serve as the evidence to assign permissions.

Step 1: Create the Strong Name

1. Create a new Windows Form project.
2. Open a Visual Studio command prompt.
3. Change to a directory near the location of your Windows Form project.
4. Issue the command “sn.exe -k codeaccesskey.snk” to create a strong naming key.
5. Edit the AssemblyInfo file in your project.
1. Change the line [assembly: AssemblyKeyFile(“”)] to [assembly: AssemblyKeyFile(@”..\..\codeaccesskey.snk”)], where the “..\..\” is the relative path from where the code compiles compared with the location of the key file generated in Step 4.
2. Change the line [assembly: AssemblyVersion(“1.0.*”)] to [assembly: AssemblyVersion(“1.0.0.0”)].
6. Compile the Windows Forms project to create the assembly. Now, you have a strong-named assembly you can use in later examples.

Step 2: Create a Permission Set

1. Open the .NET Configuration 1.1 (Control Panel -> Administrative Tools -> Microsoft .NET Framework 1.1 Configuration).
2. Expand the Runtime Security Policy, Machine, Permission Sets node in the tree display.
3. Right-click on Permission Sets and select the New… button.
4. Select the Create a new permission set option and fill in the Name and Description and click Next (as shown in Figure 1).

   

   Figure 1. Create a New Permission Set

5. Under the Available Permissions list, select the Security list item and press the Add >> button.
6. Fill in the permission settings (similar to the dialog below in Figure 2) or just grant all permissions and press the OK button.

   

   Figure 2. Available Security Permissions

7. Under the Available Permissions list, select the User Interface list item and press the Add >> button.
8. Fill in the permission settings (similar to the dialog below in Figure 3) or just grant all permissions and press the OK button.

   

   Figure 3. Available User Interface Permissions

9. Click the Finish button. Now, you’ve created a new permission set that will allow a Windows application to run, but not much else.

Step 3: Create a Code Group

1. Open the .NET Configuration 1.1 (Control Panel -> Administrative Tools -> Microsoft .NET Framework 1.1 Configuration).
2. Expand the Runtime Security Policy, Machine, Code Groups node in the tree display.
3. Right-click on the All_Code and select the New… button.
4. Provide a Name and Description for the code group (as shown in Figure 4) and click Next.

   

   Figure 4. Create a Code Group

5. Choose the Strong Name as the condition type.
6. Press the Import button and navigate to the location of the executable file compiled when you created your strong-named assembly. Double-click on the executable name. This will read the public key associated with the executable and fill in the name and version information (see Figure 5).

   

   Figure 5. Choose the Strong Name as the Condition Type

7. Click the Next button.
8. Choose CodeGuruSamplePermissionSet (or whatever you named the permission set) as the existing permission set.
9. Click Next and then Finish.
10. Right-click on the newly formed code group and select Properties.
11. Check the option This policy level will only have the permissions from the permission set associated with this code group and then click OK (see Figure 6). This will ensure that any other policies that may exist on your machine will not interfere with this example.

    

    Figure 6. Ensure That Other Policies Won’t Interfere

You have established a code group and the evidence that will result in membership in the code group. Now, demonstrate the use of the code group by adding some code to your project and trying to execute it.