About the C# CAS Basic Example

C# Code Access Security & Security Action

1. Introduction to Code Access Security

In dot net, security to the application is given through the dot net supplied Security Framework. The topic of interest is shortly called as CAS (Code Access Security). We can see the code access security at topmost level through the Dot net configuration utility. We can launch it from the administrative tools in the Control Panel. The below picture shows the path:

Accessing DotNet Configuration tools
Accessing DotNet Configuration tools

In this article, we are going to learn how one can use Code Access Security at the assembly level.

2. Code Access Security Zones

The Security Zone describes the location in which the application is running. Say; for example, a dot-net application that runs through the internet is seen as Internet Zone application. So based on the locations, Dotnet determines the zones and claims a set of securities on it. The below video shows the Security Zones on a system through dot net utility which we can launch from control panel:


Video 1: Examining the Permission Set for a Security Zone


From the above video, we got an idea of how security can be applied based on the Security Zone in which the App is running. For example, we saw Local Intranet Security Zone can only read username environment. These Dot-Not Permission Set cannot be confused with the Windows Security. Windows Security which acts on username and role groups takes the first precedence and then dot net security applies its security measures on top of it. If user logged in as a guest user, then they have only limited access even though the App runs on Trusted Zone.

Trusted Zone: A Zone that has no security limitation from dot net security point of view.

When we develop an application, based on the Security Zone in which it is going to run, DotNet decides the permission sets for it.  An assembly can elevate these Zonal Permission when a coder insists that via the assembly attributes.

3. About This Code Access Security Example

Have a look at the below screenshot:

About the C# CAS Basic Example
About the C# CAS Basic Example

The Above example will help us learn about the Code Access Security and how to apply it to an assembly. The buttons marked as 1 and 2 are used to read the system environment variables called SecTest and UserName. Here, UserName is a built-in environment variable and SecTest is the one we create for checking the Code Access Security. The text box marked as 3 is to display the value to read from  the system Env. variable.

4. Security While Reading Environment Variables

4.1 System.Security Namespace

System environment variables are secured data and we are reading those via both the button click event handlers. First, we will add a needed namespace to catch any security exception. The namespace is System.Security, and the Code is below:

4.2 GetEnvironmentVariable API

The GetEnvironmentVariable function takes the variable name and returns the value to its caller. We call this function in both buttons’ event handlers to fetch the environment variable values. And the text box txtVal will display the fetched value.  Note the usage of the SecurityException in the catch block. The handler function use this to report any security failures. We will make this happen when we move on through this article. It is just for learning purpose.

That is all the coding here. We can now build the solution and run to check how the sample application is working. The below video show how we create the SecTest environment variable and run the application to test it.


Video 2: Create SecTest Environment variable and Run EXE


5. DotNet Security Actions (CAS)

Dot net framework 2.0 and beyond gives three kinds of Security Actions for any code access say Accessing the Registry or Reading a file from secured location, etc. These three security actions are:

  1. RequestMinimum
  2. RequestRefuse
  3. RequestOptional

In the coming sections, we will try each security action one by one with our example application. Remember the fact that we tested the example in trusted mode. To check the above security actions, we should test it in a more secure environment, say; Internet Zone or Intranet Zone. We will explore how to do that shortly. We can apply each of the above security action using the attributes defined for Permission Sets. Now we will delve into these security actions one by one for the Environment Permission Set.

6. RequestMinimum – Security Action

This security action RequestMinimum checks for the security before loading the assembly into the memory. When the checked security is not granted for the assembly, dot.net refuses to load the assembly. For example, let us say, assembly doesn’t have permission to read Username environment variable. When the assembly claims to read that environment variable with Request Minimum action, dot-net cancels the assembly load with an error.

Below screen shot shows the security attribute with RequestMinimum  Action:

Setting security attribute to C# Assembly
Setting security attribute to C# Assembly

The Assembly (Marked as 1) says that the attribute is an assembly level attribute. The EnvironmentPermission (Marked as 2) class in the attribute links the RequestMinimum Security Action (Marked as 3) and the resource (Marked as 4) in which it will act on. Each PermissionSet has the associated permission class.  Once we place the above attribute in the top level of the even before the NameSpace, during the assembly load, Dotnet checks the permission grant for reading the username system environment variable. 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 to mark a specific security as optional. For Example; if we mark reading Username Environment as optional, the assembly loads whether it has permission or not. When the zone do not have permission, Dotnet throws an error at runtime while the assembly attempts to read that environment variable. But the note here is, the assembly loads leaving the security check to the run-time. Below is the attribute:

In the above code, we made read access to the SecTest Environment variable as optional at assembly level. This will allow the assembly to load, even though the zone does not have permission for the resource. In that case, Dotnet throws an exception at runtime when the code attempts to read the SecTest.

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


Video 4: Checking RequestOptional Security action


8. RequestRefuse Security Action

The RequestRefuse Security Action rejects a specific security even though the Security Zone has given access to it. Recall how the UI Permission in the past video throws the error even the zone has access to it. OK, now we will try how RequestRefuse works with the below video:


Video 5: Checking RequestRefuse Security Action


Source Code: Download CAS Security Action Example From Google Drive

Do you like this Example? Please comment about it for others!!

This site uses Akismet to reduce spam. Learn how your comment data is processed.