Code access security is a concept of .NET Framework that restricts the execution privileges of the code on the resources and its operations. Usually administrators configure security policy of the code. This is done by sets of permissions with groups of code called as Code Groups. In the next section we will look into the code groups in detail. Using Code Access Security, the code can request for permissions to execute. Once a code has requested for permission, the permissions are granted to it based on its assembly permissions security policy. We will also be covering the types of policies in the next section.

Each assembly has a set of corresponding grants. If an assembly needs to execute a method that uses other assemblies, it requests the .NET runtime for permission to execute. This process is called Security Stack Walk. According to MSDN, Security stack walk is the process of examining the permissions of each caller in the stack and determining whether the permission being demanded has been granted to each caller. If a caller that does not have the demanded permission is found, the security check fails and a SecurityException is thrown.

In the previous sections we understood that before the code executes it can ask the runtime for the permission to execute. The permission for an assembly is given by placing attributes. Placing attributes and asking permissions is known as declarative syntax. (It should be noted that it is not mandatory for the code to ask for the permission.)

Let us understand this with the help of an example. If we have an application that reads and writes to the local hard disk then the application must have FileIOPermission. If the code does not request FileIOPermission and the local security settings do not allow your application to have this permission, a security exception is raised when the application attempts to write to the disk. There are 2 things that need to be understood here.

·         The local system security does not allow the application to do anything on the disk.

·         The Application does not request for the FileIOPermission.

On a different scenario, if the application requests FileIOPermission and the local security settings does not permit the application to have FileIOPermission, the application will generate the exception. But in this case, we can programmer can ensure that user will not loose any data.

Different Types of permissions

We have different types of permission sets. Let us see some of them in detail.

1.    Minimum permissions (RequestMinimum) - Permissions for the code have to run.

2.    Optional permissions (RequestOptional) - Permissions for the code that can be bypassed to run without them.

3.    Refused permissions (RequestRefuse) - Permissions that you want to ensure will never be granted to your code, even if security policy allows them to be granted.

Listing 1 shown below is the code written in C# that explains the request for permission from an assembly using attributes.

Listing 1

[assembly:PermissionSetAttribute(SecurityAction.RequestMinimum, Name = "FullTrust")] 

As per MSDN, the definition of Code Group is "a logical grouping of code that has a specified condition for membership." A code group has some permission sets associated with it. Based on these permission sets, the security policy will be configured by the administrators. A named permission set consists of at least one permission set and a name and description for the permission set. Administrators can use named permission sets to establish or modify the security policy for code groups. Please find the built-in named permission sets provided by the common language runtime.

·         Nothing - no permissions (code cannot run)

·         Execution - permission to run (execute), but no permissions to use protected resources

·         Internet - the default policy permission set suitable for content from unknown origin

·         LocalIntranet - the default policy permission set within an enterprise

·         Everything - all standard (built-in) permissions, except permission to skip verification

·         FullTrust - full access to all resources

Let us see how a code group forms in configuration file and then discuss each element in detail. Listing 2 forms a code group. The code group is of the type NetCodeGroup. This is from the assembly “mscorlib.” The NetCodeGroup class provides the Web permission to the site from which the assembly is downloaded. It forms the union of PolicyStatement objects and grants permission based on the same. A PolicyStatement consists of a set of granted permissions and possible special attributes for the code group. There are three types of schemes available for NetCodeGroup: Http, Https and File. The IMembershipCondition defines the test to determine whether a code assembly is a member of a code group. The IMembershipCondition has a method Check which does the same. AllMembershipCondition is the class which represents the membership condition that matches all the code.

Listing 2

<CodeGroup
 class="System.Security.Policy.NetCodeGroup, mscorlib, Version=2.0.0.0,
 Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Name="Internet_Same_Site_Access"
Description="All Internet code gets the right to connect back to the site of its origin.">
<IMembershipCondition
 class="System.Security.Policy.AllMembershipCondition, mscorlib,
 Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"/>
<connectAccessRules>
<codeOrigin scheme="file"/>
<codeOrigin scheme="http">
<connectAccess scheme="http"
port="$origin"/>

The figure below shows different types of code groups that inherit from the abstract class code group.

Figure 1

A policy level consists of a set of code groups organized into a single rooted tree, a set of named permission sets that are referenced by the code groups to specify permissions to be granted to code belonging to the code group and a list of fully-trusted assemblies.

1.    Enterprise: security policy for all managed code in an enterprise. This is the topmost hierarchy for applying policy level settings.

2.    Machine: security policies for all managed code run on the computer

3.    User: Security policy for all managed code run by the user. For the current user the security settings get applied.

4.    Application domain: security policy for all managed code in an application

The figure below shows the configuration wizard for the .NET Framework 2.0. The policy level Enterprise security policy has Code Groups, Permission Sets and Policy Assemblies within it.

Figure 2

We have been discussing a Permission Sets, Code group and Policy Level. Now, we will try to understand how an Administrator configures the code access security using .NET Framework configuration wizard. Figure 3 shows editing the Permission set to full trust. We have other options, such as Skip Verification, Execution, Local intranet, Internet and Nothing.

Figure 3

The figure given below shows the modification of Membership condition to all code. We have all the options listed with their meanings.

·         All Code –  all assemblies meet this condition

·         Application Directory – all assemblies in the directory or a child directory of running app

·         Hash – all assemblies with a hash that matches the given hash

·         Publisher – all assemblies digitally signed with a specified certificate

·         Site – all assemblies downloaded from a specified site

·         Strong Name – all assemblies with a specified strong name and public key

·         URL – all assemblies downloaded from a specified URL

·         Zone – all assemblies that originate from one of five specified zones listed below

·         My Computer – Internet, Local Intranet, Trusted Sites and Untrusted Sites

Figure 4

Code access security is a concept of .NET Framework that restricts the execution privileges of the code on the resources and its operations. The permission for an assembly is given by placing attributes. Placing attributes and asking permissions is known as declarative syntax.