Code Access Security using C# in VS.NET 2005

Prior to the .NET Framework all Windows applications were having free access to all of the local resources, including the registry, file system, event logs, environment variables or available printers.

What's required is an integrated security model that grants code permission to resources based on "evidence" pertaining to the encapsulating assembly. The .NET Framework provides that security model; it's called Code Access Security.

Overview

The CLR implements Code Access Security based on the "evidence" gathered about assemblies. When we talk about evidence means it includes things as:

• What is the Strong Name (if any)? 
• Who is the publisher (if digitally signed)? 
• From where is the assembly being loaded? 
• If the assembly was downloaded from the Web, what is the URL of the source directory?

The CLR assigns assemblies to Code Groups based upon the evidence gathered. Code groups are organized in hierarchical structure. Each code group has one and only one Membership Condition that specifies which assemblies should be assigned to the group. Each code group also has a set of Permissions which indicate what actions the assemblies in that group are permitted to perform. When the .NET Framework is installed, default code groups, membership conditions, and permissions are enabled, which reduce the likelihood of our computer or network being victimized by malicious code.

Policy Levels

There are up to four security policy levels. They are listed below with the configuration Files information:

1. Enterprise-%Systemroot%\Microsoft.NET\Framework\version\Config\enterprise.config
2. Machine-%Systemroot%\Microsoft.NET\Framework\version\Config\security.config
3. User-%UserProfile%\Application Data\Microsoft\CLR Security Config\version\security.config
4. AppDomain- N/A

The AppDomain policy level is not enabled by default. It must be explicitly specified programmatically but the Enterprise, Machine, and User security policy configurations are loaded from XML-based configuration files. AppDomain security policy is specific to a specific application running in an operating system process.

Code Groups

Brief about the code group. Each policy level contains its own set of code groups. The diagram below depicts a typical sample of a Machine policy level code group hierarchy:

Security Policy Administration

Let's look at the actual administration of security policy. We'll also see the code examples, which will demonstrate the net effect of the modifications we make to the security policy.

The command line tool caspol.exe or the MMC Snap-in mscorcfg.msc can be used to edit the XML files that define the security policy (at the Enterprise, Machine and User levels). If our intention is to create scripts to alter security policy for a large number of machines, caspol.exe would be the best tool to use.

The default Enterprise and User level code group hierarchies are much less interesting because they consist of only the All_Code code group. We can expand the expandable code group nodes to view all of the code groups in the hierarchy. Click on the LocalIntranet_Zone code group and then click on the Edit Code Group Properties link in the right pane. When the 'LocalIntranet_Zone Properties' dialog appears, click on the 'Permission Set' tab. We will see a list of permissions that are granted to the LocalIntranet_Zone code group.

By default the LocalIntranet_Zone code group does not have permissions to several resources, including the registry and the file system. Click here to view a complete list of the .NET Framework code access permissions.

When we click on the 'Membership Condition' tab, we will see that the membership condition type is 'Zone' and the specific zone is 'Local Intranet'. By default, assemblies that originate on an organization's intranet and assemblies that are loaded via a UNC path meet this membership condition. We can configure the 'Internet', 'Local Intranet', 'Trusted Sites' and 'Restricted Sites' zones through the 'Internet Options' dialog in Internet Explorer.

The following simple code example will help demonstrate how Code Access Security permissions effect the execution of managed code. This windows application will read the registry sub-keys under the HKLM\Software\Microsoft\.NetFramework registry key and display the key names in the listbox:

Code:-

Microsoft.Win32.RegistryKey rkey;
try
{
       rkey = Microsoft.Win32.Registry.LocalMachine.OpenSubKey(
       "Software\\Microsoft\\.NetFramework", false);
       string[] skNames = rkey.GetSubKeyNames();
       for (int i = 0; i < skNames.Length; ++i)
       {
            listBox1.Items.Add("Registry Key: {0}" + skNames[i]);
       }
       rkey.Close();
}
catch (System.Security.SecurityException ex)
{
      MessageBox.Show("Security Exception Occured: {0}"+ ex.Message);
}

If we compile and execute the application, we will see that the names of the registry keys under the  .NetFramework key are displayed. The CLR granted our assembly permissions to execute and read the registry.

 

Output