Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


Managing .NET Code Access Security (CAS) Policy : Page 2

Toward the end of the project cycle is not the time to figure out Code Access Security. Learning how .NET handles evidence, permissions, code groups, etc. now will put you that much further ahead for your next project.




Application Security Testing: An Integral Part of DevOps

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.

Table 1: Evidence types that ship with .NET.

Evidence Type


Application Directory

Location where the application resides.


Assembly hash using crypto algorithms such as MD5 or SHA1.

Permission Request

Identifies what permissions an assembly must have.


Authenticode signature of the publisher.


Web site the code was launched from.

Strong Name

Assembly strong name.


URL where code was launched from.


Zone code was launched from.

.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.

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.

Table 2: .NET permissions and protected resources.

Permission Type



ASP.NET hosted environment


Active Directory




Environment variables


Windows EventLog


Open and save common dialogs


Reading and writing to files


Isolated storage




ODBC data sources


OLE DB data sources




Performance counters in the Windows Performance Monitor




Reflecting on types


Windows registry


Working with permissions, security, and unmanaged code


Access to Windows services


Socket IO


SQL Server


User interface drawing


Access Web pages

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.

Figure 1: Default permission sets.
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.

Code Groups
Code groups are at the heart of setting CAS policy. Through a series of logical operations on a hierarchical set of code groups, you control what managed code is allowed to do on your system. Code groups are atomic elements in CAS policy that map evidence to permissions. Figure 2 shows the default code groups that ship with .NET.

Figure 2: Default code groups.
A single code group contains two members: a membership condition and a permission set. The membership condition accepts a type of evidence. If the provided evidence meets the requirements of the membership condition, the permission set associated with that code group will be used in further evaluation of CAS policy.

For example, in the My_Computer_Zone code group, the Evidence type is Zone. The Membership Condition states that the zone must be MyComputer and the Permission Set is FullTrust. If the assembly was launched from a local directory, the Membership Condition will be met and the FullTrust permission will be added to the set of permissions used to resolve CAS policy. However, if an assembly was launched from a different computer on the LAN or from across the Internet, this code group would not contribute to the set of permissions an assembly is granted.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



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