Before Making Any Security Policy Change: Administration Strategies

Security breaches can be very costly, but not all such breaches are the result of actual errors in software. Many security breaches are a result of mismanagement or mistakes in security policy administration. Some of the consequences of administrative mistakes are

• Unintended side effects of security policy changes allow unsafe code to run, which can lead to the loss of files or the theft of information.

• Security policy has been too strongly tightened, preventing legitimate applications from running properly and, therefore, causing severe productivity loss.

Before dashing to make any security policy changes, you should carefully consider the following questions and heuristics. Only after such consideration should you go ahead and alter security policy. The .NET Framework Security system will only be able to enforce what security policy tells it to enforce.

Do You Have to Change Policy at All?

When thinking about changing security policy, the first question that you should ask yourself is whether you truly need to make a change at all. If an application that you expected to run causes a security exception, it may very well be that the security system is just doing its job in preventing illicit access to protected resources. Generally, there are only three main scenarios that should prompt you to change security policy:

• If an assembly can access resources that it should not have access to (it accesses the file system, registry, or even runs at all), security policy should be tightened for that assembly.

• If an assembly that should legitimately run does not execute or run properly due to security restrictions, security policy should be made less restrictive for that assembly.

• A previous change to security policy introduced an error (either opened a security hole, prevented a legitimate assembly from running properly, the enterprises security guidelines have changed, and so on), security policy should be changed accordingly.

You should think hard about changing security policy if you are motivated by a scenario different from the three defined scenarios. For example, an assembly displaying a window asking you to change security policy or trying to run an application from the Internet that throws a security exception does not necessarily represent sufficient reason to change security policy.

A special case to consider is if the security policy has not been changed at all so far, so the default security policy is still active. Default security policy has been designed to be a safe default that should suffice for most scenarios in which managed code is run. The following is a list of the main characteristics embodied by default policy:

• All assemblies running on the My Computer zone have access to all resources. This means that security is effectively not enforced for all assemblies that have been explicitly installed on the local machine.

• All assemblies from the intranet zone run in a tight security context. For example, this means that intranet assemblies must verify and have no access to the file system, registry, security system, or write access to environment variables. However, assemblies from the intranet are allowed to read certain environment variables, do unlimited User Interface interaction with the user, use the safe file storage system (Isolated Storage), and connect back to their place of origin, among other things.

• All assemblies from the Internet zone are prevented from running by default. An administrator needs to explicitly change policy to enable specific applications to run from the Internet.

• All assemblies from the Trusted site zone are executed within tight security constraints. For example, any assemblies run from a Trusted site have only limited UI access, no direct file system, registry, or environment variable access, among other restrictions.

• All assemblies from the Restricted site zone have no rights whatsoever. This means assemblies in that zone are not executed.

You should go ahead and make the respective policy change only if you are certain that you want to deviate for an assembly or set of assemblies from these characteristics of default policy.

An example of a valid change to default policy is if an enterprise decided not to allow any code coming from the intranet to execute except for a few trusted applications. This requires changing the Intranet zone policy to withhold all permissions from code in that zone, while adding in policy to trust specific software publishers or strong names.

Generally, you should always remember that default policy has been carefully crafted to protect your computer's resources from illicit access by code originating from anywhere but your local machine.

Think of the Worst Case Scenario

Before making any policy change, you should not only consider whether that change will get the job done. It is also imperative to ask yourself what the worst case security vulnerability could result from your policy change. For example, if you want to enable a specific application running from your enterprise's intranet to get full access to all protected resources, you could accomplish this by giving full access to all protected resources to all assemblies from the intranet. Although this will accomplish the task, it will also enable all other assemblies on the intranet to run with full trust. These may be assemblies over which you exercise scant or no control. Consequently, when making security policy changes, it is essential to stay task focused and to consider the worst possible case that your changed security policy may encounter.

Make the Policy Change with the Least Possible Impact

To reduce the possibility of creating unintended side effects due to your policy change, you should make that change to policy that will accomplish the task at hand but affects as few assemblies as possible. For example, if you want to enable a certain assembly running from the intranet to receive full trust to access protected resources, you could do so by introducing a code group into the policy that grants that level of trust based on the Internet site at which the application is found. However, this would give all assemblies at that site the same rights that you only want to allot to a specific application. A safer way to do this would be to either use the assembly's hash or strong name as a basis to target just that specific assembly in your policy change. The more changes you make to policy, the more important this guideline becomes, because side effects can accumulate and, in combination, can open a security vulnerability.

Pre-Plan the Policy Structure of Your System

You can think of policy as a way to partition the set of all assemblies into subsections. Each of these subsections receives a specific amount of trust to access protected resources. In a way, security policy is a highly dimensional categorization mechanism that sorts assemblies into administratively defined trust categories. As you have learned earlier in this book, default policy partitions the world of assemblies along the lines of zones. You should think hard about whether you need to further partition these categories contained in default policy or introduce your own. For example, you may have a specific software publisher, such as a contractor company supplying your enterprise with custom applications, that you always want to grant full access to all resources on the system. In such a case, you should add another trust category to your policy that grants full trust to access all protected resources based on the strong name of the contractor company.

Generally, you should think of all the categories of assemblies that should receive special security consideration, compare this list with the default policy, and then see if you need to make any changes.

Consider the Interaction with Operating System Settings

As you will remember from the previous chapter, the .NET Framework security system operates on top of whatever security settings the operating system enforces. Thus, managed code can only access those resources that both the operating system and the .NET Framework security system allow the code to access. In some cases, this will mean that changes not only to the .NET Framework security policy but also to operating system settings are needed. For example, if you change policy to allow an assembly running from the intranet to have read access to certain parts of the file system, that assembly may still be prevented from doing so, even after your policy change, for the simple reason of running into a DACL restriction. This problem usually only occurs in cases in which you attempt to relax .NET Framework security policy. Thus, prior to widening managed security policy, consider whether this also implies changes to operating system security settings.

Document Your Changes

It is good practice to maintain a log of the policy changes you have undertaken. In the case of problems with the current security policy, this may enable you to pinpoint exactly which change to the policy created the problem.

Enterprise level configuration file

Machine level configuration file

User level configuration file