Code Access Security

In the past two issues, we have discussed the role-based security aspect of the security subsystem of a .NET framework. While this is based upon allowing an executing piece of code to do a particular task based upon who they are, ie, what security context the code is running under, there's also a notion of security in the .NET framework that allows permissions being given to a piece of code, either at the metadata level or programmatically, to allow/disallow resource access (such as file system folders), irrespective of what security context the code runs under.

Thus, it's possible that while an application is running under the administrative security context, if one of the executing methods has not been allowed access to C:\, then any code within that method's implementation will not be allowed to access C:\, even if the administrative context has full access rights to the folder.This is one of the attributes of another aspect of the .NET framework security, termed as CAS (Code Access Security). This article helps you understand the various components of CAS and shows how it can be used.

Permission sets



The core function of CAS is to control resource access by the executing code depending upon the permissions the code has not, rather than what permissions the logged in security context (ie, user) has. In addition, CAS can also:

• Restrict which code can call your code, thus, preventing the malicious/hacker code from making your code a scapegoat.
• Identify code, including the author of the code and origin of the assembly containing the executing code.
  
  
  
  CAS has the following three major components that help it achieve these objectives.
• Permission Set: It contains one or more permisions, like whether the managed code can have a UI or not, whether it can write to a particular file system folder or not, or whether it can create
  
  AppDomains.
• Code Group: This has two components:

Using the configuration tool to modify the Enterprise, Machine and User security policies Listing the code groups and permission sets in security policies

a. A membership condition, which when satisfied, will allow an assembly to be part of the code group. For instance, if a code group has a membership condition as

http://www.xyz.com/*, then all assemblies that are downloaded or referenced from this URL will be regarded as member of the specified code group.

b. A permission set that has been assigned to this codegroup. All assemblies that are member of a given code group will have the permissions defined in the associated permission sets to be applied to them when the code therein is executed.

The matrix explains the effective CAS permission calculation across security policies Changing permission set for the My_Computer_Zone code group in Machine security policy

• Security Policy: It comprises one or more codegroups and one or more permission sets. The four security policies that exist in the .NET framework are Enterprise, Machine, User and
  
  AppDomain.
  
  
  
  Each security policy contains its set of code groups and permission sets. First the Enterprise policy is applied and then Machine policy, followed by the User policy. AppDomain policy is applied only for ASP.NET Web applications. For the typical applications, the chain ends at user policy. Each applied policy overrides the settings of the previously applied policy, in case there is an overlap. Also, of the above four policies, the first three can be configured from Start>Control Panel>Administrative Tools>Microsoft.NET Framework Configuration as shown below:

If you expand the '+' sign next to the security policies and delve down the tree hierarchy, you will see the default code groups and permission sets.

An exception is thrown when managed code is executed with 'Nothing' permission set applied to Attempting to execute Stack Trace for CAS security permission that was absent with the assembly

Permission evaluation



Now that we have understood the basic components of CAS, you might be wondering how the permission evaluation occurs and how effective permission is calculated which is applied to an assembly, especially when the assembly is member of a code group that is present in more than one security policies. Well, it's rather simple and follows the following two rules.

• Within a security policy, if the assembly is deter mined to be a member of more than one code group, then 'union' of the permissions (associated with the member code groups) is applied.
• Next, if the assembly is member of more than one code group across security policies, then
  
  'intersetion'of the permissions, ie, the common set of permisions is applied.

This is better understood by the following matrix.

Application executes when FullTrust permission set is reapplied to the My_Computer_Zone code group

CAS in action



Now that we know the CAS basics and how permission evaluation takes place, let's try it out. Have you ever wondered why the managed code written by you runs once you build it and execute it? Well, it executes because it belongs to the 'My_Computer_Zone' code group that has the 'FullTrust' permission set associated with it. The membership condition for this code group is 'any code that originates from your machine'. And since the code is running on your machine, the membership condition of the My_Computer_Zone code group is fulfilled and the permissions of the associated permission set (which happens to be FullTrust) are applied. Thus, the code executes and can do anything!

Now, change this permission set to Nothing (this permission set implies that the executing code can't do anything, even if you are logged in as the administrator).

To start off, create any managed application-it doesn't matter if it's console or WinForms based. Once created, attempt to execute it. You will see that your application executes. Now in the Machine security policy, right click on the

My_Computer_Zone code group and select the 'Permission Set' tab. Change the permission set to 'Nothing'. Click on OK to commit the change and close the dialog.

Now, you can execute your application as a regular user or even as an administrator. When you try execution, you will be thrown an exception, as shown below.

Click on No, on the debugger prompt and you will get the 'Stack Trace', which shows that permission to load the assembly was not given (even when you logged in as the administrator).

Now, go through the same steps and set the permission set back to FullTrust and attempt your application execution. Your application will now execute without any issues.

Conclusion



We have looked at what CAS is, how it works and what its impact on your application-more importantly noting that it doesn't care how you are logged on as (administrator, user or guest), but focuses upon the permissions assigned to your assembly. Next, we will see how our code can control access to itself, demand different permissions and interface with CAS closely.

Kumar Gaurav Khanna