Sunday, January 10, 2016

[ C# ] - Code Access Security and Security Action Examples

1. Introduction

In dot net framework, security to the application is applied through the dot net supplied Security Framework. The topic of interest is shortly called as CAS (Code Access Security)”. The code access security at top most level can be seen through the “Dot net configuration” utility which can be accessed through the administrative tools as shown in the below screenshot:

Fig 1. Accessing DotNet Configuration tools
Fig 1. Accessing DotNet Configuration tools

In this article, we are going to understand how Code Access Security can be used at the assembly level.

2. CAS - Security Zones

The "security zone" identifies the location from which the application is running. Say; for example, the dotnet application that runs through the internet is seen as internet zone application. So based on the locations, the zones are identified and appropriate set of securities are applied to it. The below-given video shows the security zone on a system through dot net configuration utility.

Video 1: Examining the Permission set for a Zone

From the above video, we got an idea of how security can be applied based on the zone in which the application is running. For example, we saw only username environment variable can be read by any dotnet application that runs through the local intranet. These dot not permission set cannot be confused with the windows security. Windows Security (Operates on Username and role groups) takes the first precedence and then dot net security applied on top of it. If user logged in as a guest user, then they have only limited access even though the application runs on “Trusted Zone” (A Zone that has no security limitation from dot net security point of view).

When you develop an application, based on the location in which it is going to run, the permission sets are assigned to it.  An assembly can elevate permission coming from the zone.

3. About the Example

 Have a look at the below screenshot:

Fig 2. About the Example
Fig 2. About the Example

Above given example is used to understand the code access security applied to an assembly. The buttons (Marked as 1 and 2) are used to read the System environment variables called SecTest and UserName. UserName is a built-in environment variable and SecTest is created for checking the code access security. The textbox (marked as 3) is used to display the system environment variable.

4. Code to Read Environment variables

1) System environment variables are secured information and we are reading those through both the button click event handler. First, we will include a required namespace to catch any security exception. The Code is below:

//Sample 01: Name Space inclusion
using System.Security;

2) The “GetEnvironmentVariable” function is called in both button event handlers to retrieve the environment variable values. And these values are displayed in the textbox txtVal.  Note the usage of the SecurityException” in the catch block and this is used to get information related to any security failures (That is going to happen soon when we are progressing through this article).

//Sample 02a: Read Environment variable SecTest
private void btnRead_Click(object sender, EventArgs e)
        txtVal.Text = Environment.GetEnvironmentVariable("SecTest");
    catch (SecurityException Ex)
        MessageBox.Show("Security Exception Caught: " + Ex.Message);

//Sample 02b: Read Environment variable UserName
private void btnWrite_Click(object sender, EventArgs e)
        txtVal.Text = Environment.GetEnvironmentVariable("UserName");
    catch (SecurityException Ex)
        MessageBox.Show("Security Exception Caught: " + Ex.Message);

That is all the coding here. You build the solution and run to check how the sample application is working. The below video creates the SecTest environment variable and runs the application.

Video 2: Create SecTest Environment variable and Run Exe

5. Security Actions for Assembly

Dot net framework 2.0 and beyond provides three kinds of security actions for any given security say Accessing Registry or Reading a file from secured location etc. These three security actions are:

  1. RequestMinimum
  2. RequestRefuse
  3. RequestOptional

In this section, we will examine each security actions one by one with the application tested in the previous sections. Remember the fact that we tested the Application in trusted mode. To check the above security action we should test application in more secure environment say; "Internet Zone" or "Intranet Zone". I will explain how we can do that shortly. Each of the above security action is applied to assembly using the attributes defined for Permission Sets. Now we will examine these security actions one by one for the "Environment Permission" set.

6. "RequestMinimum Security" action

This security action checks for the security before loading the assembly into the memory. When the checked security is not granted for the assembly, the assembly load is prohibited. Say; for example, let us say, assembly don’t have permission to read environment variable “Username” and when we claim to read that environment variable with request minimum action, the assembly load cancelled with an error.

The below screen shot shows the security attribute with Request Minimum Action:
Setting security attribute to Assembly
Fig 3. Setting security attribute to Assembly
The "Assembly" (Marked as 1) says that the attribute is an assembly level attribute. The "EnvironmentPermission" (Marked as 2) class in the attribute is used to link the "Security action" (Marked as 3) and the resource (Marked as 4) in which it can be applied. Each "PermissionSet" has the associated permission class.  Once we place above attribute in the top level (Even before the NameSpace), during the assembly load, the permission to read the system environment variable username is ensured. The below video shows checking our sample application with this attribute:

Video 3: Checking RequestMinimum Security action

7. "RequestOptional Security" action

The “RequestOptional Security" action is used mark a specified security as optional. For Example; if I mark Reading User Name Environment as optional, the assembly is loaded whether the assembly has permission or not. When assembly do not have permission, the error is thrown at runtime while an attempt is made to read that environment variable.

//Sample 04:Place Assembly level security actions here
[assembly: EnvironmentPermission(SecurityAction.RequestOptional, Read="SecTest")]

In the above code, Read Access to the SecTest Environment variable is made optional. This will allow the assembly to load even through the zone has not permission. In that case, an exception is thrown at runtime when an attempt is made to read the SecTest.

Also, note that the RequestOptional security sets RequestRefuse security action for all other permission sets. The video.3 shows how the optional request for SecTest environment variable is set to successfully load the assembly.

Video 4: Checking RequestOptional Security action

8. "RequestRefuse Security" action

The “RequestRefuse” security action is used reject a specified security even though the zone has granted access for it. Remember how the UI permission (In the previous video) throws the error even the zone has access to it. OK, we will examine how request refuse works with the below video.

Video 5: Checking RequestRefuse Security Action

Source Code: Download

No comments:

Post a Comment

Leave your comment(s) here.

Like this site? Tell it to your Firend :)