Improve the Security of a .NET Framework Application with CAS

The .NET Framework introduces a new layer of security, called Code Access Security. This layer lives on top of the OS security, and lets you control what a given assembly can and can’t do, just like the OS lets you define the rights of a user or group.

Before we dive into the details, there’s something (which may seem obvious at first, but is a particularly good thing to remember on the exam): whatever permissions you grant to a code, it will never have more rights than the user who runs it (just recall ASP.NET and IIS).

In the previous post, I wrote about permissions. The first important layer of CAS is the control of them. There are default permission sets, defining what an assembly can do. They are as follows:

FullTrust Exempts an assembly from CAS checks.
SkipVerification Enables an assembly to bypass permission checks.
Execution Enables an assembly to solely run.
Nothing No permissions granted. Not even enough to run the given assembly.
LocalIntranet The main restriction is that the assembly is not allowed to tamper with the file system, only through file dialogs.
Internet A restrictive permission set, but safe.
Everything Grants all permissions, but still checks the assembly.


The previous permission sets are associated with an assembly with the help of code groups. Code groups are like user groups in an OS. An assembly can be the member of multiple code groups. Membership is granted with the help of evidences. An evidence is something the with the assembly identifies itself. There are seven types of it, namely: Application Directory, Hash, Publisher, Site, Strong Name, URL and Zone. Let’s link everything together:

Code Group Evidence Permission Set
My_Computer_Zone Zone: My Computer FullTrust
LocalIntranet_Zone Zone: Local Intranet LocalIntranet
Internet_Zone Zone: Internet Internet
Restricted_Zone Zone: Untrusted sites Nothing
Trusted_Zone Zone: Trusted sites Internet


I hope the table above makes sense and explains everything. Last but not least, there are the monstrous beasts of security policies. If anyone is still reading me, they are Enterprise, Machine, User and Application Domain. With security policies, different permission sets can be assigned to different code groups on each level of them. As a rule of thumb, lower level policies cannot grant more right to an assembly than specified in a higher level policy (for example, you cannot widen the permission set on the Application Domain level, but you are able to narrow it).

Everything above can be set by a single tool: Caspol.exe. I wouldn’t like to write about it, it has just too many command-line arguments, check it out on MSDN.

Now some programming to the end. There are some interesting classes for example the PermissionSet class, which represents a collection of IPermission instances. It has a counterpart called NamedPermissionSet, the main difference is that NamedPermissionSet has a string name, and can have a string description, too. Using PermissionSet classes make your life easier, since you can call Demand, Assert, etc. on a collection of permissions, you don’t have to do it one-by-one.

CodeAccessPermission class has static methods to revert to the security policy state before asserting, denying or calling PermitOnly.

You can use the SecurityManager class to programmatically access and manipulate the given security configuration.

Further Readings

Code Access Security

Code Access Policy Tool (Caspol.exe)

SecurityManager Class

Tags: , , , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: