Code Access Security Part - 1 (.NET Framework Tools Series)

Introduction

Today we are going to look at Code Access Security.

Code access security is a feature of .NET that manages code depending on its trust level. If the CLS trusts the code enough to allow it to run then it will execute, the code execution depends on the permission provided to the assembly. If the code is not trusted enough to run or it attempts to perform an action which does not have the required permissions, then its execution is stopped and the application exits.

Code access security is primarily about protecting resources like your local disk, network, user interface from malicious code. It is not a tool for protecting software from users as is a general misbelief.

Code access security is based upon Code Groups and Permissions.

Code Groups

In Windows, we have user groups and every user belongs to a group. We do not give permissions to users on an individual basis but rather it is more convenient to create a group and give permissions to this group. In the same way, we have code groups bring code that have similar characteristics and execution permissions together.

E.g. One of the predefined code groups is Internet. If we say that this code belongs to Internet code group, this code has only those permissions which are defined by this group. Since the Internet code group does not have access to your local access, all the applications executing under this code group will not have permissions to access the local hard disk.

Permissions

They are actions that each code group is allowed to perform, e.g. Permissions to access the user interface. This permission management can be done at three levels:

1. Enterprise
2. Machine
3. User

"All Code" code group is the root group. All the code groups are under this code group. If an assembly does not match a code group in the hierarchy code groups below, it is not searched.

For an assembly to be a member of any code group, it needs to fulfill its membership condition. Each code group has one and only one membership condition. This is the list of membership conditions in which "All code" membership condition is at the root.

Let us view all the available code group membership conditions:

1. Go to Visual Studio Command prompt and type caspol /help
2. Scroll to the bottom and you will see the following membership or mship options where <mship> can be:
   • allcode - All code
   • appdir - Application directory
   • custom <xml_file> - Custom membership condition
   • hash <hashAlg> {-hex <hashValue>|-file <assembly_name>} - Assembly hash
   • pub {-cert <cert_file_name> | -file <signed_file_name> | -hex <hex_string>} - Software publisher
   • site <website> - Site
   • strong -file <assemblyfile_name> {<name> | -noname}{<version> |-noversion} - Strong name
   • url <url> - URL
   • zone <zone_name> - Zone, where zone can be: (MyComputer, Intranet, Trusted, Internet, Untrusted)

   Zone is the most commonly used membership condition. These zones are managed from Internet Explorer using the security options.

3. Go to Internet Explorer. ... Tools ... Options ... Security Tab ... And you will see all these options.
   Note: These options are set from Internet Explorer, but they apply to the whole machine.
4. Type caspol.exe - lg. This command will list all the code groups without the descriptions.
   If you want to see the descriptions, type caspol.exe -ld.
5. To view the code groups of an assembly e.g. type caspol -resolvegroups <DLLName>.dll. It will show a similar output:
   
   

   Level = Enterprise
   
   Code Groups:
   1. All code: FullTrust
   
   Level = Machine
   
   Code Groups:
   1. All code: Nothing
   1.1. Zone - MyComputer: FullTrust
   
   Level = User
   
   Code Groups:
   1. All code: FullTrust
   Success

6. In order to understand code access security completely, we need to understand Permission sets very well. Type caspol -lp | more. You will see an entire list of permissions in the form of XML tags. We will look at a few most frequently used permission sets:
• SQLCLientPermission: Permission to access SQL Database
• UIPermission: Permission to access user interface
• FileIOPermission: Permission to read, write or append to file as well as create folders
• Printing Permission: Permission to print
• WebPermission: Permission to make or accept connections to/from the Web

.NET has provided us with predefined permission sets a.k.a. named permission sets. They are:

• FullTrust
• Execution
• Nothing
• LocalIntranet
• Internet
• Everything

Note: Only the last three can be modified. The first three cannot be altered.

You can also view assembly permissions with caspol:

caspol.exe -rp <Your Assembly>.dll

Note: In one of my previous articles, we had seen how to view assembly permissions with permview.exe.

Now let's view the current permission sets for each code group at various policy levels.

CAS policy levels exist either at enterprise, user or machine level.

By default, when you list groups using caspol, machine level policy details are displayed to you. If you want to see user and enterprise policy details, type -u or -en as follows:

caspol -u -lg /* for user */
caspol -en -lg /* for enterprise */

By default, .NET gives FullTrust permissions to "ALL Code" Code group at enterprise and user level.

The question now is how we determine which policy level will be used.

Well, CAS takes an intersection of all the three policy levels, i.e. user enterprise and machine. Hence if you have made any changes on your machine's policy, your administrator can easily override it by changing the user or enterprise policy.

In part 1, we have seen the code access groups, permission sets and the different policy levels. In part 2, we will create a sample app and see how we can manage security policy.