Managing .NET Code Access Security (CAS) Policy

Code Access Security (CAS) is the .NET Common Language Runtime (CLR) mechanism for maintaining security based on the identity of code.Most developers don't have to work with CAS on a daily basis because the .NET Framework libraries take care of much of the work involved in securing code. However, when you do need to work with CAS, having a good understanding of CAS policy management is essential. Waiting until the eleventh hour in the project lifecycle and realizing that you need to configure security policy is painful. For example, if you have a Smart Client application that runs over Internet Explorer, you will need to consider what permissions your application requires and how you are going to configure policy so that your code will run on a client machine. Or, suppose that your application defined a custom permission for a scenario not already covered by the permissions that ship with .NET. Here again you need to understand CAS policy. This article discusses the essential elements of CAS (evidence, permissions, and policy), shows how .NET CAS policy works, and explains reasons for making various policy decisions.

CAS and the Elements of Policy

CAS security is based on the identity of managed code. The need for CAS arose out of the constant execution and threat of malicious code on the Internet. A quick look at what has been done up to now in the way of security can help set perspective on the value of CAS.

Previous efforts to stem the tide of malicious code were not enough. There was, and still is, role-based security that maintains security based on the identity of the person that is running the code. Role-based security was, and still is, an important element in system protection. But in this day and age it is not enough.

Certificates and sandboxes for ActiveX controls, applets, and script were the first widespread commercial means to apply security measures to code. Initially these efforts simply prevented code from running until the user gave the code permission. However, these security implementations either gave code all permissions or none, thereby preventing it from running; there wasn't a middle ground that gave users a choice. In the case of ActiveX controls, non-technical users had to choose whether or not to let unknown code run on their system, exposing a dangerous situation for someone to make an uninformed mistake and allow malicious code to execute. All-or-nothing and on-demand security have their place but they are not enough.

Internet Explorer improved upon some code security by introducing zones that allowed code to receive a certain amount of trust based on where it was launched from. This good idea is now part of the present CAS strategy. However, CAS takes this idea and goes further.

In CAS, code contains evidence that identifies its origin. The evidence could be a zone, publisher, or one of several other types of evidence. CAS policy evaluates the evidence and resolves/assigns permissions that a piece of code is allowed to have. .NET supports many permission types, giving you a fine level of granularity in choosing what code can do. Additionally, you can configure CAS policy on multiple levels, letting you explicitly plan and specify a policy that keeps your system secure and allows only necessary code to run to let you get your work done.

Evidence

Evidence represents the origin of code. At run time, the .NET Common Language Runtime (CLR) gathers evidence on an assembly that it uses for security as the application executes. Table 1 identifies the type of evidence supplied by .NET by default. Although this article focuses on existing evidence types, you should know that if one of the pre-existing evidence types doesn't meet your needs, you can create your own.

.NET calculates evidence at run time because it cannot resolve the origin of an assembly until that assembly is executing. For example, if you run an application from a directory of the workstation you're working on, it has Site evidence of localhost. If that same application were launched from a Web site, such as C# Station, its Site evidence would be http://www.csharp-station.com. It is the same assembly, but because its origin differs between invocations, its evidence is different.

Permissions

Evidence is the input to CAS policy and permissions are the output. Permissions specify what a piece of code is allowed to do. Code can only perform actions for the permissions it is given?there are no defaults.

Table 2 shows what permissions come with .NET. While this article only focuses on existing permissions, because CAS is configurable, you can build your own permission classes. To help make it easier to apply policy, .NET lets you combine permissions into permission sets.

When you install .NET on your computer, the installation program added the Microsoft .NET Framework 1.1 Configuration tool (Figure 1) to your system to make it easier to work with permissions and configure CAS policy. You will find the Microsoft .NET Framework 1.1 Configuration under Administrative Tools (under the Control Panel). If you have multiple versions of .NET installed on your system, you will have more than one version of this Configuration tool. Be sure to select the one for the version of .NET you need to set policy with.

Once you've opened the Microsoft .NET Framework 1.1 Configuration tool, select Runtime Security Policy, choose Machine, and then choose Permission Sets. Each Permission Set contains multiple permissions, making it easier to define policy.

You may have noticed two Permission Sets named FullTrust and Everything. FullTrust gives blanket full trust for all permissions, existing and future, that an application will ever need. The Everything permission set covers all permissions that ship with .NET. The Everything permission set does not include the Skip Verification Security permission, which allows an assembly to bypass CLR verification.

By: Joe Mayo

Joe Mayo is an author, independent consultant, and trainer specializing in .NET technologies. He operates the C# Station Web site (www.csharp-station.com) and is a Microsoft Most Valuable Professional (MVP). Joe is author of C# Unleashed (Sams) and C#Builder Kick Start (Sams). For more information about Joe, please visit www.mayosoftware.com.

jmayo@MayoSoftware.com