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