Chapter 6: Software Restriction Policy for Windows XP Clients
Updated: April 13, 2006
Software restriction policy provides administrators with a way to identify software and control its ability to run on local computers. This tool can help protect computers that run Microsoft® Windows® XP Professional against known conflicts and safeguard them against malicious software such as viruses and Trojan horse programs. Software restriction policy integrates fully with the Active Directory® directory service and Group Policy. You can also use it on stand-alone computers.
This chapter has a different structure than the previous chapters in this guide because of the way software restriction policy works. The previous chapters provided recommendations about how to configure Group Policy setting options. Software restriction policy requires an administrator to define the applications that are allowed to run on the client computers in your environment and to then determine the restrictions that the policy will apply to the clients.
When you implement software restriction policy, the first decision you must make is whether the default security level will be Unrestricted or Disallowed. If the default security level is Unrestricted, then all software will be allowed to run and you will need to configure additional rules to block specific applications. The more secure approach is to configure the default security level to Disallowed, which means no software will be allowed to run, and then configure additional rules to allow specific applications. You can apply software restriction policy to multiple computers through domain–based Group Policies or to individual computers through local Group Policy.
Important: It is important that you thoroughly test all of the policy settings that are discussed in this guide before you deploy them to production systems, especially software restriction policy settings. Mistakes in the design or implementation of this feature can cause considerable user frustration.
Software restriction policy provides a number of ways to identify software, as well as a policy–based infrastructure to enforce rules on how the identified software may run. Computer users must comply with the guidelines that are established in the software restriction policy by the administrator in their environment.
You can use software restriction policy to accomplish the following:
Software Restriction Policy Architecture
Software restriction policy provides the following powerful features:
Software restriction policy implementation includes three phases:
Unrestricted or Disallowed Settings
A software restriction policy consists of two parts:
You can set the default rule that is used to identify software to either Unrestricted or Disallowed—which allow you to either run or not run all software, respectively.
If you set the default rule to Unrestricted, an administrator can define exceptions or a set of programs that are not allowed to run. Use the Unrestricted default setting in an environment with loosely managed client computers. For example, you can restrict users' ability to install a program that will conflict with existing programs by creating a rule to block it.
A more secure approach is to set the default rule to Disallowed and then allow only a specific set of programs to run. The Disallowed default setting requires an administrator to define all the rules for each application and ensure that users have the correct security policy settings on their computers to access the applications that they are allowed to run. The Disallowed default setting is the more secure approach for organizations that want to protect Windows XP client computers.
Four Rules to Identify Software
Rules in a software restriction policy identify one or more applications and specify whether they are allowed to run. The enforcement engine in Windows XP queries the policy’s rules before applications are allowed to run. To create a rule, you need to identify applications and then categorize them as exceptions to the Disallowed default setting. Each rule can include comments to describe its purpose.
A software restriction policy uses the following four rules to identify software:
The Hash Rule
A hash is a digital fingerprint that uniquely identifies a software program or executable file even if the program or executable file is moved or renamed. Administrators can use a hash to track a particular version of an executable file or program that they may not want users to run.
With a hash rule, software programs remain uniquely identifiable because the hash rule match is based on a cryptographic calculation that involves the contents of the file. The only file types that are affected by hash rules are those that are listed in the Designated File Types section of the details pane for Software Restriction Policies.
Hash rules work effectively in a static environment. If software in your environment is upgraded, the hash needs to be recalculated for each updated executable file. Hash rules work very well in environments that experience infrequent software changes or upgrades.
A hash rule consists of the following three pieces of data, separated by colons:
Digitally signed files use the hash value that is contained in the signature, which may be MD5 or SHA-1. Executable files that are not digitally signed use an MD5 hash value.
Hash rules are formatted as follows:
[MD5 or SHA1 hash value]:[file length]:[hash algorithm id]
The following hash rule example is for a 126-byte file with contents that match the MD5 hash value (7bc04acc0d6480af862d22d724c3b049) and the hash algorithm (denoted by the hash algorithm identifier 32771):
Each file that the administrator wants to restrict or allow needs to contain a hash rule. When software is updated, the administrator must create a new hash rule for each application because the hash values for the original executable files will not match those of the new files.
Complete the steps in the following procedure to create a hash rule for an executable file.
To create a hash rule for an existing executable file
The Certificate Rule
A certificate rule specifies that a software publisher's certificate (used for code-signing) must exist before a program is allowed to run. For example, an administrator can require signed certificates for all scripts and ActiveX controls. Allowable sources that comply with the certificate rule include:
A certificate rule is a strong software identification method because it uses signed hashes in the signature of the signed file to match files, regardless of name or location. Unfortunately, few software vendors use code-signing technology, and even those that do typically sign a small percentage of the executable files that they distribute. For these reasons, certificate rules are generally used for a few specific application types such as ActiveX controls or internally developed applications. For example, this guide recommends that organizations digitally sign scripts that are used to manage computers and users so that all unsigned scripts can be blocked. A hash rule can be used to identify exceptions to a certificate rule.
Enabling Certificate Rules
Certificate rules are not enabled by default. Complete the steps in the following procedure to enable certificate rules.
To enable certificate rules
For detailed instructions about how to digitally sign files, see the “Step-by-Step Guide to Digitally Signing Files with Test Certificates” section of the "Using Software Restriction Policies to Protect Against Unauthorized Software" at http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.mspx.
Many commercial Web sites have their software code-signed by a commercial certification authority (CA). These certificates are usually valid from one to several years. When you use certificate rules, be aware that the certificates carry expiration dates. You may be able contact the software publisher to find out more information about the expiration period for a published certificate. When you receive a certificate from a commercial CA, you can export it to a file to create a certificate rule. Complete the steps in the following procedure to export a certificate.
To export a certificate
The Path Rule
A path rule specifies either a folder or a fully qualified path to a program. When a path rule specifies a folder, it matches any program that is contained in that folder and any programs that are contained in subfolders of that folder. Path rules support both local and UNC paths.
The administrator must define all directories from which a specific application will be launched in the path rule. For example, if a desktop shortcut is used to launch an application, the path rule must specify both the executable file and the shortcut paths to run the application. If a user attempts to run an application with only a partial path rule, the Software Restricted warning will display.
Many applications use the %ProgramFiles% variable to install files on the hard drive of Windows XP–based computers. Unfortunately, some applications are hard-coded to copy files to the C:\Program Files subdirectory, and will do so even if this variable is set to another directory on a different drive. Remember this limitation when you create and test path rules.
Using Environment Variables in Path Rules
You can define a path rule to use environment variables. Because path rules are evaluated in the client environment, environment variables allow an administrator to adapt a rule to a particular user’s environment.
The following two examples show instances of how to apply environment variables to a path rule.
Note: Environment variables are not protected by access control lists (ACLs). There are two types of environment variables, User and System. Users who are able to start a command prompt can redefine the Users environment variable to a different path. Only users in the Administrators group can change the System environment variable.
Although the two preceding examples are very useful, you may want to consider other available environment variables. For a complete list, see the “Command shell overview” at http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntcmds_shelloverview.mspx.
Using Wildcards in Path Rules
A path rule can incorporate the "?" and "*" wildcards. The following examples show wildcards that are applied to different path rules:
Registry Path Rules
Many applications store paths to their installation folders or application directories in the Microsoft Windows registry. Some applications can be installed anywhere on the file system. To locate them, you can create a path rule to look up their registry keys.
These locations may not be easily identified using specific folder paths, such as C:\Program Files\Microsoft Platform SDK, or environment variables, such as %ProgramFiles%\Microsoft Platform SDK. However, if the program stores its application directories in the registry, you can create a path rule that will use the value that is stored in the registry, such as:
This type of path rule, called a registry path rule, is formatted as follows:
%<Registry Hive>\<Registry Key Name>\<Value Name>%
Note: Any registry path rule suffix should not contain a \ character immediately after the last % sign in the rule. The registry hive name must be written completely; abbreviations will not work.
When the default rule is set to Disallowed, four registry path rules are set up so that the operating system has access to system files. These registry path rules are created as a safeguard—so that you do not lock yourself and all other users out of the system—and are set to Unrestricted. These rules should only be modified or deleted by advanced users. The registry path rule settings are:
Path Rule Precedence
When there are multiple path rules that match, the most specific rule takes precedence over the others. The following set of paths is ordered from highest precedence (most specific match) to lowest precedence (most general match):
You can use a zone rule to identify software that is downloaded from any of the following zones that are defined in Internet Explorer:
The current version of the Internet zone rule applies only to Windows Installer (*.msi) packages. Also, this rule does not apply to software that is downloaded through Internet Explorer. All other file types that are affected by zone rules are listed in the Designated File Types table later in this chapter. One list of designated file types is shared by all zone rules.
Use the information in the following table to determine which type of rule is best suited for an application’s users and environment.
Table 6.1 Determining the Best Rule for a Given Application
Software Restriction Policy Precedence Rules
Rules are evaluated in a specific order. The rules that more specifically match a program take precedence over rules that more generally match the same program. If two identical rules with differing security levels are established for the same software, the rule with the highest security level takes precedence. For example, if two hash rules—one with the security level Disallowed and one with the security level Unrestricted—are applied to the same software program, the rule with the security level Disallowed takes precedence, and the program will not run. The following list defines the precedence order for the rules, from the most specific to the least specific:
Software Restriction Policy Options
This section discusses the various enforcement options that influence the way a software restriction policy functions. These options alter the way Microsoft Authenticode® trust settings are enforced for digitally signed files. There are two enforcement options: Dynamic-link library (DLL) checking and Skip Administrators.
Most programs consist of an executable file and many supporting DLLs. By default, software restriction policy rules are not enforced on DLLs. This default setting is recommended for most customers for the following three reasons:
Because viruses primarily target executable files, some specifically target DLLs. Therefore, DLL checking is the recommended option when you want the highest possible assurance for the programs running in your environment.
To ensure that a program does not contain a virus, you can use a set of hash rules that identify the executable file and all of its constituent DLLs.
To turn off the DLL Checking option
You may want to disallow programs from running for most users but allow administrators to run all of them. For example, an administrator may have a shared computer that multiple users connect to through Terminal Server. The administrator may want users to run only specific applications on the computer, but members in the local Administrators group to be able to run anything. Use the Skip Administrators enforcement option to achieve this functionality.
If the software restriction policy is created in a GPO that is linked to an object in Active Directory, Microsoft recommends that you deny the Apply Group Policy permission on the GPO to the Administrators group and not use the Skip Administrators option. This method consumes less network bandwidth because GPO settings that do not apply to administrators are not downloaded.
Note: Software restriction policy defined in local security policy objects cannot filter user groups, and would therefore require use of the Skip Administrators option.
To turn on the Skip Administrators option
The Designated File Types Properties dialog box in the following figure lists the file types that are governed by software restriction policy. These file types are considered executable files. For example, a screen saver file (.scr), is considered an executable file because it loads as a program when you double-click it in Windows Explorer.
Software restriction policy rules only apply to the file types listed in the Designated File Types Properties dialog box. If your environment uses a file type that you want to apply rules to, add it to the list. For example, for Perl script files you may choose to add .pl and other file types associated with the Perl engine to the Designated file types: list under the General tab of the Designated File Types Properties dialog box.
Figure 6.9 The Designated File Types Properties dialog box
See full-sized image
For the GPO design that is defined in this guide, the file types .mdb and .lnk are removed and .ocx is added. The following table lists the designated file types.
Table 6.2 Designated File Types
You can use the Trusted Publishers Properties dialog box to configure which users can select trusted publishers. You can also determine which, if any, certificate revocation checks are performed before you trust a publisher. With certificate rules enabled, software restriction policy will check a certificate revocation list (CRL) to ensure that the software's certificate and signature are valid. However, this process may decrease performance when signed programs are started.
The options on the General tab of the Trusted Publishers Properties dialog box shown in the following figure allow you to configure settings that are related to ActiveX controls and other signed content.
Figure 6.10 The Trusted Publisher Properties dialog box
See full-sized image
The following table shows trusted publisher options that are related to ActiveX controls and other signed content.
Table 6.3 Trusted Publisher Tasks and Settings
Software Restriction Policy Design and Deployment
This section describes how to administer software restriction policy with Group Policy snap-ins, things to consider when you edit a policy for the first time, and how to apply a software restriction policy to a group of users. A variety of issues that relate to software restriction policy deployment are also discussed.
Integration with Group Policy
You can administer software restriction policy with Group Policy snap-ins to a set of client computers as well as to all the users that log on to the computers. The policy is applied to the Desktop OU and the Laptop OU that are defined in this guide.
The administrator should create a separate GPO for the software restriction policy. This method provides a way to disable the Group Policy without disrupting other policies that are applied to the object if unexpected problems should arise.
A local policy should be configured for the stand-alone client computers in your environment as described in Chapter 5, "Securing Stand-Alone Windows XP Clients" of this guide.
Designing a Policy
This section describes the steps to follow when you design and deploy a software restriction policy. Policy design requires you to make several decisions, all of which are described in the following table.
Table 6.4 Important Policy Design Considerations
Note: Although this guide recommends that software restriction policy be enforced at the computer level there are many cases in which enforcement at the user level will make sense. For example, an organization with shared computers such as Terminal Server application servers or call center workstations may want to allow certain users to run a suite of applications, but block all other users from access.
Microsoft recommends that you create a separate GPO for software restriction policy, so that if you need to disable the policy in an emergency it will not affect the rest of your domain or local policy.
Also, if you accidentally lock down a workstation with software restriction policy in the design phase of your OU, restart the computer in Safe mode, log on as a local administrator, and then modify the policy. Software restriction policy is not applied when you start Windows in Safe mode. After you start the computer in Safe mode, run Gpupdate.exe and then restart it.
For the best security, use ACLs in conjunction with software restriction policy and do not give users administrative privileges. Users may try to rename or move disallowed files or overwrite unrestricted files to circumvent software restriction policy. Use ACLs to deny users access to perform either of these actions. Users who are members of the local Administrators group will be able to bypass your software restriction policy implementation; therefore Microsoft recommends that you do not give users administrative privileges whenever feasible.
Login scripts are usually located under SYSVOL on the domain controller or a centralized server. The domain controller often changes with each login. If your default rule is set to Disallowed, be sure to create rules that identify the locations of your logon scripts. If the logon servers have similar names, consider the use of wildcards to locate them, or use the logon script name with unrestricted settings.
Note: Test new software restriction policy settings thoroughly in test environments before you apply them to your domain. New policy settings may act differently than originally expected. Thorough tests will diminish the chance that you will encounter a problem when you deploy the software restriction policy settings across your network.
Stepping Through the Process
Use the following information to guide you through the process of software restriction policy design and application of the design as a GPO to the laptops and desktops in your environment.
Step 1. Create a GPO for the OU
Locate the OU that was created for the desktops or laptops in your environment. If you are working on a stand-alone client computer, the policy settings are located in the Local Computer Policy. In this policy, click Properties, and then create a new GPO. Name the policy according to your organization's naming convention. Remember, this policy will only be used to enforce software restrictions.
Step 2. Set the Software Restriction Policy
Highlight the GPO and click Edit. Traverse the tree until you locate Windows Settings\Security Settings\Software Restriction Policy. The first time you edit the policy you will see the following message:
No Software Security Policies are defined.
This message warns you that you will define default values when you create a policy. These default values can override policy settings from other software restriction policies. Because no software restriction policy settings have been set yet, use the default settings to start. Right-click the Actions menu and select New Software Restriction Policies.
Step 3. Set Up the Path Rules
After you determine which applications and scripts the workstations will use, you can set up the path rules. Some programs launch other programs to perform tasks, and the software applications in your environment may depend on one or more programs that support other programs. Inventory and installation documentation about the currently installed software is very useful for tracking path rules. An example of a workstation design might include the following guidelines:
Step 4. Set the Policy Options
The following options include the recommended policy settings for the design that is defined in this guide. These options alter the enforcement behavior scope or the Authenticode trust settings for digitally signed files.
Before you trust a publisher, select the Check: Publisher option when you design the GPO to ensure the policy will validate certificates.
Step 5. Apply the Default Settings
It is a best practice to configure the policy to the default Unrestricted setting. This method ensures that the policy is properly initialized before software restrictions are applied. After you review the policy settings, reset the default setting to Disallowed.
Step 6. Test the Policy
If the computer is part of a domain, move the computer into the OU container where the policy is applied. Restart the test computer and log on to it. The test plans should have instructions about how each of the applications should work when the policy is applied. Run the applications to ensure they have full functionality and that you can access all of their features. After you have validated the functionality of the applications, simulate an attack on the applications to ensure that the policy has no security vulnerabilities.
If the computer is a stand-alone client, log on to the test computer and follow your test plan. After you have validated the applications, launch the simulated attack again to ensure that the policy has no security vulnerabilities.
Deploying Software Restriction Policy
After the policy is thoroughly tested, apply it to the desktop or laptop OU in your environment. If it is for a stand-alone client computer, apply it to the Local Computer Settings on the client. Open the MMC Computers and Users snap-in and traverse the directory until you reach the OU container for the desktops or laptops. Then, create the new GPO with the Group Policy Object Editor. Edit the properties and apply the appropriate policy settings based on the information in the following tables to the Software Restriction Policy under Windows Settings\Security Settings.
Table 6.5 Security Levels
Table 6.6 Additional Rules
Table 6.7 Enforcement on Files and Users
Table 6.8 Designated File Types
Table 6.9 Trusted Publishers
Software restriction policy provides administrators with an effective way to identify and control software on computers that run Windows XP Professional. You can create policies to block malicious scripts, lock down computers in your environment in various ways, and prevent applications from running. In an enterprise organization, it is a best practice to manage software restriction policy with GPOs and to customize each policy to accommodate the needs of the different user groups and computers. Microsoft recommends that you not attempt to manage user groups in a stand-alone environment.
When correctly applied, software restriction policy will improve the integrity and manageability of computers in your organization and ultimately lower the ownership and maintenance costs of the operating systems on those computers.
The following links provide additional information about Windows XP Professional security-related topics.