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
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
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:
|
1 2 |
//Sample 01: Name Space inclusion using System.Security; |
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
//Sample 02a: Read Environment variable SecTest private void btnRead_Click(object sender, EventArgs e) { try { 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) { try { txtVal.Text = Environment.GetEnvironmentVariable("UserName"); } catch (SecurityException Ex) { MessageBox.Show("Security Exception Caught: " + Ex.Message); } } |
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:
- RequestMinimum
- RequestRefuse
- 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
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:
|
1 2 3 4 |
//Sample 04:Place Assembly level security actions here [assembly: EnvironmentPermission( SecurityAction.RequestOptional, Read="SecTest")] |
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
Categories: C#
Tags: Code Access Security (CAS), GetEnvironmentVariable, RequestMinimum, RequestOptional, RequestRefuse, Security Actions, Security Zones
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.