CAS Administration

Administering code access security is a task that programmers and users both need to know how to accomplish. Programmers need to know how to administer CAS in order to set up their development and deployment environments. Users need to know how to administer code access security and security policies in order to grant rights to different applications on their computers or in their corporate networks.

Modifying CAS Policy

Policy is the set of permissions, permission sets, and code groups for your computer and your enterprise. The policy is essentially the set of rules by which all managed code executed on your machine must abide.

There are some guidelines as to when you should modify policy. The policies that are configured by default when the .NET Framework is installed on your PC are configured that way for a specific reason. If you modify that policy, you run the risk of opening holes in security that malicious applications can take advantage of or holes in security that will enable careless code to cause damage.

If there is an application installed on your PC that originated from an untrusted or partially trusted zone (such as the Internet or an intranet) that requires more than the default permissions, you will need to modify the default policy in order to trust that code.

Often publishers will create suites of applications. If you want your computer to automatically apply the same trust level to all applications created by the same publisher, you will need to modify the default security policy. Although there are several reasons for promoting applications to a more trusted level of security, there are also reasons for tightening the security policy. For example, you could modify the security policy in such a way that even applications that are part of the fully trusted zone cannot access certain resources unless you specify otherwise.

Policy Administration Tools

There are several tools that you can use to modify the security policy for your .NET Framework installation. There are both command-line utilities and MMC (Microsoft Management Console) snap-ins that enable you to administer various aspects of the .NET Framework configuration, including security policy. A command-line tool called CASPOL.EXE gives you manual (and fairly complex) access to the security policy configuration. The security policy for the .NET Framework is stored in .config files on the system.

The most commonly used tool (and easiest to use) is the .NET Configuration tool. You can find this tool by either launching Start, Run, mscorcfg.msc, or by opening your Administrative Tools folder and launching Microsoft .NET Framework 1.1 Configuration. When you launch this application, you will see various options in a tree view on the left side. The option of interest for this chapter is the Runtime Security Policy folder icon. Expand that tree and you will see that you can set policy for the enterprise, for the current machine, and for the current user.

TIP

Note that policies overwrite each other in descending scope. Therefore, if you allow code to have certain permissions at the enterprise level and you deny those same permissions on that machine, the code will be denied those permissions when executed on your computer. The same type of descending-order filtering applies to user-scope security policy.

When you click on the Runtime Security Policy folder icon, the main content panel will show you the following list of tasks:

• Increase Assembly Trust This task launches a wizard that will enable you to increase the level of trust that belongs to a specific assembly. The wizard will let you browse for a specific filename.

• Adjust Zone Security This task launches a wizard that enables you to increase the permissions granted to code originating from the different zones such as Internet, Intranet, My Computer, and the rest.

• Evaluate Assembly This is a handy new wizard that enables you to browse for an assembly. You will then receive a report showing you the permissions and security policy associated with that assembly.

• Create a Deployment Package This is perhaps one of the most underutilized tools. It launches a wizard that creates a deployment package that actually bundles a collection of security policy settings that will be committed to a destination system when the package is installed. Because the output is an .msi file, it can be distributed throughout an enterprise via group policy, manual copies, or through the Systems Management Server update mechanism.

• Reset All Policy Levels This task resets your entire security policy to the settings they were at the time of the original install (the default settings). Because this will destroy all changes that you have made to your security policy since installing .NET, make sure that this is really what you want to do before executing this task.

Increasing Assembly Trust Levels

Click on the Trust an Assembly hyperlink and you will see a wizard form appear. The first question you will be asked is whether the changes to the trust level apply to the current user or the current machine. This enables you to let certain applications run with additional security permissions while certain users are using the application, or to let those applications run with additional privilege for everyone using the current computer.

After you have browsed to the assembly (typically a DLL or EXE) that you want to trust and have clicked the Next button, you will see the screen shown in Figure 34.2.

Figure 34.2. The Trust an Assembly dialog, prompting for assembly or publisher.

This dialog prompts you for whether you want to trust the assembly or all assemblies created by the assembly publisher. This happens if the assembly you are trying to trust has a strong name. If the assembly doesn't have a strong name, you can't identify the publisher, so the wizard will never give you the option of trusting the publisher. The dialog illustrates a user having browsed to a sample class library called CASLibrary.

If you have a strongly named assembly (or want to create one for this example), choose to increase the trust for just that one assembly and set the trust level to Full Trust. Confirm the settings and you have completed the Increase Assembly Trust wizard.

Adjust Zone Security

The Adjust Zone Security wizard prompts you to change the trust level that is associated with each zone. Unless you are really sure what you are doing, you probably don't want to mess with the settings in this area. The reason is that if you give too much trust to a zone without knowing the full consequences, you could be opening your computer to intrusion, malicious code, or poorly written code that can do damage to your system.

The dialog in Figure 34.3 shows the security adjustment screen for the various zones. If you have ever opened the security adjustment dialog from within Internet Explorer, this dialog should look familiar. In fact, it should look exactly the samethese settings are also used by Internet Explorer.

Figure 34.3. The Security Adjustment Wizard dialog for .NET security.

Evaluate Assembly

The Evaluate Assembly task enables you to examine the current security permissions of a specific assembly. When the security policy is displayed, it takes into account enterprise, machine, and user policy as well as explicitly granted security systems.

When you start this wizard, it asks whether you want to view permissions that have been explicitly granted to the assembly or view all the code groups that grant permissions to the assembly.

A code group is a logical organization of similar code defined by some criteria. When you earlier told the Trust wizard that you wanted to trust the assembly, it created a code group that consisted of that one assembly and only that assembly. It then granted that one code group full trust. The way CAS works is that permissions and policy only apply to code groups; they do not apply to individual files. As shown in Figure 34.4, one of the code groups currently granting permissions to the assembly is Wizard_0. Wizard_0 is the code group that was automatically generated by the wizard when you trusted the test assembly.

Figure 34.4. The results of evaluating the code groups contributing to my assembly's permissions.

You might be wondering how you can know that the code group Wizard_0 is actually the one that was created by the wizard you ran earlier. To verify this fact, you can take a look at the list of code groups on your machine. Expand the Machine node under the Runtime Security Policy, and then expand the Code Groups node, and finally expand the All_Code parent group (code groups are arranged in hierarchies of inherited characteristics). At the bottom, you'll see Wizard_0 (if you were following along, you might see other automatically generated code groups if you have been playing with security). Click it (you'll notice that its description indicates it was auto-generated by the .NET configuration tool) and then click Edit Code Group Properties. The screen shown in Figure 34.5 will appear.

Figure 34.5. The Code Group Properties dialog, showing the Membership Condition tab.

By clicking the Membership Condition tab, you can see that the configuration tool set up a code group that indicates a strong name, including the public key, name, and version number of the assembly created earlier. Click the Permission Set to see that the code group has indeed been granted full trust.

Creating a Deployment Package

A deployment package is one of the most important tools for a programmer creating an application that will be deployed to servers or desktops that requires special treatment by security policy. You can't assume that all installations will have the same default policy. Many organizations disable the capability for managed code to make use of the network, even if that code was installed directly on the computer. In such a case, your code must be specifically granted the permissions it needs in order to access the network.

To make sure that your code has the permissions it needs, you can create a code group for your code by specifying the public key and possibly the version number of your strongly named assemblies and grant it the appropriate permissions. Then when you create a deployment package, it will contain that code group and permission set. Any client installing that package will have its security policy modified in order to grant trust to your code.