Code Access Security(CAS) : 2- Configuration

Published 06-05-2009 11:34 AM | Saed Shela

 

 

After my first article that was  introduction to CAS , and as i have promised today we will make some configurations on the CAS.

Our configuration will be on .Net Framework  2.0 , to be honest i didn’t  practice it on 3.5 , but I'll soon and I'll post my experience here.

The .NET Framework Configuration tool (Mscorcfg.msc) is a Microsoft Management Console (MMC) snap-in supplied with the .NET Framework that provides a graphical interface to manage various aspects of .NET configuration. We will talk here only about the  Security configuration using the mentioned tool. You can perform many different CAS-related tasks, including the following:

  • Adding new permission sets
  • Adding new code groups
  • Increasing an assembly’s trust
  • Assembly Evaluation in order to determine which permissions to assign
  • Adjusting zone security
  • Resetting policy levels

image

As you can see in the above picture. We have three Security Policy types (Enterprise , Machine , User ). Enterprise is for the assemblies that run on servers and it can be configured with the AD DS help. Machine is  the assemblies that is configured in the Machine level (per machine ).

Assembly Evaluation in order to determine which permissions to assign

Before you start configuring the security of the assembly , you need to know what this assembly hold for you . You need to evaluate the assembly in order to determine which permissions you must assign .  The following are the steps to evaluate the assembly using .NET Framework 2.0 Configuration:

  1. Right Click on the “Runtime Security Policy “ , then click evaluate assembly

image 

    2.     You will see the above screen , you need to choose the assembly that you want to evaluate , then choose the type (High l, and Low level).Then choose your policy level that you want to evaluate.(All Levels will show you everything )         

    3.  Clicking Next will show you the below screen.( It depend on the assembly you have choose ) Here you go the evaluation is in front of you now .

   image

Depending on the assembly that i have choose , my assembly have nothing to do with security. In other words it have the default(Minimum)  permissions. So this assembly need  good security care. Lets configure it.

Creating named permission sets

We have two ways to this , even by code or by configuration tool . lets see Both.

Using Configuration Tool :

Click any policy you need to  create the permission set on it . Then fo to Permission Sets and right click then New.. .

Actually the assembly that I'm using in my tutorial is sloppy one ( i cannot trust it ) , its a third part assembly (from the internet ) , and i don’t want it to rune my registry so i will configure it  correspondingly .

image

You have two options , either by  creating it using the wizard or by importing the definition from XML file. Well lets do it by the first way.

Fill the Name and description then click Next .

image

Then select the Permission that you want to grant and Click ADD . In my example i will select Registry and click add then the Above screen will appear . What i need to do is just specify the Registry Key that i want protect. The click finish and your permission set is created.

 

Programmatically creating Permission set (Write to XML file)

In the Above example we have experienced the Import of Permission Set from Xml file. The question is how to create this XML file . We wil grant some secuirty permissions in this example.

The complexity of information in the XML description of a named permission set means that it is easier to create this information programmatically. This is easy to do by creating a System.Security.NamedPermission object, populating it with permission objects, and calling the ToString method on the System.Security.SecurityElement returned by the ToXml method. The following code demonstrates the creation of the TestSet named permission set (whose XML description we just listed) and displays it to the console :

   1: // Create an empty NamedPermissionSet
   2: NamedPermissionSet ps = new NamedPermissionSet("TestSet", PermissionState.None);
   3:  
   4: // Add an unrestricted FileIOPermission        
   5: ps.AddPermission(new FileIOPermission(PermissionState.Unrestricted));
   6:  
   7: // Add a SecurityPermission with Assertion and Execution permissions
   8: ps.AddPermission(new SecurityPermission(SecurityPermissionFlag.Assertion |
   9:     SecurityPermissionFlag.Execution));
  10:  
  11: // Display an XML version of the named permission set to the console.
  12: Console.WriteLine(ps.ToXml(  ).ToString(  ));

 

How to Add a Code Group


To add a code group, start the .NET Framework 2.0 Configuration tool and perform
the following steps:

  1. Expand the My Computer node and then expand Runtime Security Policy.
  2. Expand Enterprise, Machine, or User, depending on the policy level in which
    you want to define the code group.
  3. Expand Code Groups, expand All_Code (if possible), and examine the existing
    child code groups. If the code group that you want to create defines a subset of
    permissions for an existing code group, click that code group. Otherwise, click
    All_Code.
  4. Click Add A Child Code Group.
  5. On the Identify The New Code Group page, type a name and a description, and
    then click Next.
  6. On the Choose A Condition Type page, specify the condition type for the code
    group by choosing the evidence that the runtime will use to identify the code
    and then click Next.
  7. On the Assign A Permission Set To The Code Group page, select the Use
    Existing Permission Set option if one of the current permission sets exactly
    meets your needs. Otherwise, select the Create A New Permission Set option
    and then click Next.
  8. If you selected the Create A New Permission Set option, perform the following
    steps:
    a. On the Identify The New Permission Set page, specify a name and description
    and then click Next.
    b. On the Assign Individual Permissions To Permission Set page, click the permissions
    you want in the permission set and click Add. For each permission,
    specify the permission settings that are unique to that permission,
    click OK, and then click Next.
  9. On the Completing The Wizard page, click Finish.

Other Security Policy Administration Options

Here we outline a number of other operations available through Mscorcfg.msc that you may find useful. By right-clicking the Runtime Security Policy node in the console tree,.

image

The commands available to you are:

New...

Creates a new policy level based on the default security configuration . You can also specify the location where the policy file will be stored.

Open...

Opens a new policy level from a specified file.

Reset All...

Allows you to reset all security policy to the default configuration . You can also reset individual policy levels to the default settings by right-clicking the individual policy level nodes in the console tree and selecting "Reset" from the shortcut menu.

Adjust Security...

Provides a simple interface through which to adjust the default machine security policy You can configure the level of trust you want to grant to each of the Internet Explorer zones, which modifies the named permission set assigned to that code group.

Evaluate Assembly...

Allows you to test an assembly to see what code groups the assembly is a member of and what permissions policy resolution would grant to the assembly.

Trust Assembly...

Allows you to define the minimum level of trust that will be assigned to an assembly.

Create Deployment Package...

Allows you to create a Windows Installer (.msi) file containing the definition of a security policy level from the current machine. Running this file on a target machine will configure the policy level of that machine. This simplifies the task of configuring security policy on a large number of machines, but .NET contains no mechanism to perform the distribution process. You can simply send the file to people that need it via email or use the normal software distribution processes used by your organization.

 

Conclusion: 

This was the second article in CAS , and as i have talked before we will have another three articles to cover most of the CAS tools and usage.

I hope that this article was helpful for you all.

 

Thank You,

Saed Shela

Filed under:

Comments

# Huthaifa Afanah said on June 5, 2009 12:32 PM:

Thanks .. regarding the .NET 3.5 configuration I it will not be different because .NET 3.0/.NET 3.5 is using CLR 2.0 which is the same with .NET 2.0

# Clothing said on September 7, 2009 3:01 AM:

Wow! Its imposible... I'm realy shocked :/