Code Access Security with Microsoft .NET Framework

WEBINAR:On-Demand

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.

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.

Change the line [assembly: AssemblyVersion("1.0.*")] to [assembly: AssemblyVersion("1.0.0.0")].

Compile the Windows Forms project to create the assembly. Now, you have a strong-named assembly you can use in later examples.

Provide a Name and Description for the code group (as shown in Figure 4) and click Next.

Figure 4. Create a Code Group

Choose the Strong Name as the condition type.

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

Click the Next button.

Choose CodeGuruSamplePermissionSet (or whatever you named the permission set) as the existing permission set.

Click Next and then Finish.

Right-click on the newly formed code group and select Properties.

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.

Compile and run the program. You should see a dialog similar to Figure 7, which tells you that your assembly was evaluated and the evidence presented put you into a restricted group. As a result, not everything you try to do will be allowed.

Figure 7. The Evidence Presented Put You into a Restricted Group

Click the button you added to your form.

You should see a message box that displays information on the SecurityException that was generated (see Figure 8).

Figure 8. Information on the Generated SecurityException

Step 5: Grant Access to Read a File

Go back to the .NET Configuration 1.1 tool.

Go into the Runtime Security Policy, Machine, Permission Sets, and right-click on the CodeGuruSamplePermission set created earlier. Select the Change Permissions... option.

Under the Available Permissions list, select the File IO list item and press the Add >> button.

Complete the Permission Settings (similar to the dialog below in Figure 9) or just select the unrestricted access option. (I chose the most restrictive option, which is generally a good idea from a security perspective).

Figure 9. Permission Settings to Grant Access to Read a File

Click the OK button, followed by the Finish button.

If you execute your project again, you should ultimately receive a message box indicating that the program was able to read the file, assuming the file exists and is in a location where you have read permissions. Recall that the evidence-based security works on top of Win32 security, so if the operating system isn't granting you permissions to read the file, you're still not going to be able to read the file.

Stay Tuned for Part 2

This lengthy example demonstrated how you could use the security policy to allow or deny actions to assemblies. The second part of this two-part series will explore the System.Security.Permissions namespace. It looks at imperative and declarative security checks and overriding security checks with the Assert() method.

About the Author

Mark Strawmyer

Mark Strawmyer is a Senior Architect of .NET applications for large and mid-size organizations. He specializes in architecture, design and development of Microsoft-based solutions. Mark was honored to be named a Microsoft MVP for application development with C# for the fifth year in a row. You can reach Mark at mark.strawmyer@crowehorwath.com.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.

Thanks for your registration, follow us on our social networks to keep up-to-date