Windows XP and Windows Server 2003 include a new feature called Software Restrictions, which allows you to control what programs can run on the computer and prevent potentially unsafe software from being able to run. This strategy gives you a way to prevent the running of unauthorized programs that might pose a security threat or contain viruses and will help prevent the installation of Trojans through which hackers can gain access to the computer.
What are software restriction policies?
First, a little history: With Windows 2000, Microsoft introduced the concept of trusted code through a feature called driver signing. This provides a way to verify that a piece of software (in this case, a hardware device driver) has been tested and works properly with the operating system. This was done through the issuance of a digital signature. You could set the system to block the installation of any drivers that didn't include the Microsoft digital signature.
Software restriction policy, as implemented in XP and Windows Server 2003, takes the idea of trusted code much further. You can now control whether all types of software applications (not just drivers) can be installed by classifying each program as trusted or not trusted, based on restriction levels and rules that you configure.
Restriction levels and rules
Restriction policies can be set for one of two security levels: unrestricted or disallowed. The unrestricted level is used for software that you want to be able to run (using the rights assigned to the account of the user who is logged on). The disallowed level prevents the software from running at all, no matter what rights the user might have. You can set a default rule at either of these levels. If you set the default as unrestricted, any programs that you don't specify will be allowed to run. Software access rights for users will be determined by each user's access rights (as set in the User Rights section of Group Policy). If you set the default as disallowed, only the programs that you specify will be allowed to run.
A warning on setting Disallow as the default
Setting the default as disallowed provides greater security, but might prevent employees from running needed programs if they aren't on the list of programs specifically allowed. Perhaps more importantly, some programs must run other programs in order to accomplish particular tasks. Even though the primary program is specifically allowed, it might not be able to function correctly if you haven't specified other programs that it uses. You should be very careful when setting Disallow as the default.
The rules you set up are for the purpose of specifying exceptions to the default. If the default is disallowed, you need to set up rules that specify programs you want to allow to run. If the default is unrestricted, you do the opposite—create rules to specify programs that should not be allowed to run.
There are four types of rules that can be used in restriction policies:
- Hash rules
- Certificate rules
- Path rules
- Internet zone rules
We discuss each of these rule types in the section on how software restriction policies work.
Restriction polices don't replace the other mechanisms provided in Windows for controlling software installation (such as group policy settings to restrict the right to install software based on user or group account, removal of the Run command from the Start menu, and so forth). Rather, it gives administrators an additional way to exert control over what can run on your computers.
Antivirus software is still vital
Microsoft cautions that, although software restriction policies can prevent the running of unauthorized programs that might be infected with viruses, you should always run a good antivirus program regardless of the restriction policies you have in place. Restriction policies do not check software for virus definitions, and viruses can be disseminated through e-mail, documents, and other methods.
How software restriction policies work
Software restriction policies work essentially like other Group Policy. You create them with the Group Policy Object Editor MMC and apply them to GPOs that can be assigned to local computers, sites, domains or organizational units. In this article, we focus on Windows XP local policies.
In XP, software restriction policies are configured through the Local Security Settings (accessed via Start | Control Panel | Administrative Tools).
Configuring software restriction in a domain
To configure restriction policies for a domain or OU, use Active Directory Users and Computers (ADUC) to open the properties of the domain or OU and select the GPO from the Group Policy tab. Then, in the GPO Editor, you'll have software restriction policies under either the Computer Configuration node (for machine policies) or the User Configuration node (for user policies). You'll have to expand Windows Settings under the appropriate node, and then expand Security Settings to find the Software Restrictions folder.
In the domain environment, like other Group Policy, restriction policies can apply to either users or machines. A machine policy is applied at bootup. A user policy is applied at logon. Machine policies are applied regardless of what user logs on to the machine, and user policies follow a user from one machine to another within a Windows domain.
Configuring Restriction Policies
As you can see in Figure A, the Software Restrictions Policies folder contains two folders: Security Levels and Additional Rules. There are also three additional configuration items: Enforcement, Designated File Types, and Trusted Publishers.
|Local software restriction policies are set through XP's Local Security Settings MMC.|
Each of these elements is used as follows:
- The Security Levels folder is used to set the default security level. When you double-click this folder, you see two choices in the right pane: Disallowed and Unrestricted. The current default level is indicated by a checkmark. To change the default, right-click the level that is not currently set as the default, and select Set As Default from the context menu.
- The Additional Rules folder is used to create new certificate, hash, Internet zone, and path rules (exceptions to the default). There are no rules defined here until you explicitly create them. To create a new rule, right-click the folder and select the type of rule you want to create from the context menu. We will discuss rules in more detail in the next section.
|You can select to exempt DLL file types from restriction policies, and to exempt local administrators from application of the policies.|
|You can add or remove file types (designated by extension) to be considered executable code.|
|You can choose which users are allowed to select trusted publishers and define criteria for checking for revoked certificates.|
While the other configuration options for software restrictions are pretty straightforward, configuration of rules is a little more complex. However, rules are the heart of your restriction policies, so it's important to understand the various types of rules, when each is appropriate, and how to configure them.
If you're familiar with basic cryptographic concepts, you probably know that a hash is a fixed-length value that represents a string of characters generated by the application of a hashing algorithm (also called the hash function) such as Message Digest (MD) 5 or the Secure Hash Algorithm (SHA).
Hash rules identify software files by their hashes. The hash on the file is compared with the one specified by the rule. If they match, the rule is applied. This can be useful because the hash value remains the same if the executable file is moved to a different location on the disk or if its name is changed. Note, however, that the hash value will change if anyone tampers with the contents of the file itself, and this would allow the software restriction policy to be circumvented if the unrestricted default is selected.
When you create a new hash rule by selecting New Hash Rule from the context menu when you right-click the Additional Rules folder, you first select the file that you want to hash, as shown in Figure E.
|A hash value is created for the executable file you select when you make a new hash rule.|
If the file has been hashed before, only hashes calculated using Software Restriction policies are recognized. However, if you used Software Restriction policies to calculate a value somewhere else, you can copy and paste that hash value in the File Hash text box. Normally you would browse for an executable file and calculate the hash. Remember that the file you select must have an extension that is in the Designated File Types list.
Digital certificates are based on public key cryptography and are designed to prove the identity of a user, computer, or in this case, a program. A certificate rule identifies files based on their certificates. This applies only to certain types of executable files, most notably scripts and installer packages (.msi files). Certificate rules are not used to identify .exe and .dll files.
You create a certificate rule by selecting New certificate rule from the context menu after right-clicking the Additional Rules folder. You'll be asked to type in or browse for the certificate that applies to the file.
Internet zone rules
The Microsoft Internet Explorer Web browser (MSIE) allows you to set up security zones, including the following:
- Internet zone: contains all sites that haven't been put into any other zone
- Local computer zone: contains Web sites stored on the local computer
- Local intranet zone: contains Web sites located on an internal network (intranet)
- Restricted sites: contains Web sites that have been identified as dangerous
- Trusted sites: contains Web sites that have been identified as safe
With zone rules, you can identify Windows installer packages based on the zone where the program runs, as specified through MSIE. Zone rules apply only to installer packages (.msi files).
When you create a zone rule by selecting New Internet Zone Rule from the right context menu after right-clicking the Additional Rules folder, you must select one of the Internet zones from the bulleted list above.
A file's path shows where that file is located within the directory structure. You can create rules based on the file path, but it is important to understand that moving the file to a different location on the disk or changing its name will cause the path rule to no longer apply to it. Path rules are useful for allowing or disallowing all programs within a particular folder.
When you create a path rule by selecting New Path Rule from the context menu after right-clicking the Additional Rules folder, you must type in or browse for the path where the program file is located.
Order of precedence
If there are multiple rules configured, they are applied in order of precedence as follows:
- Hash rule
- Certificate rule
- Path rule
- Internet zone rule
This means hash rules have the highest precedence and will override rules of other types, and so forth. If a program has two different path rules assigned, the more specific one will have highest precedence. Thus, if there is a rule that applies to a particular folder and another that applies to a subfolder within it, the rule that specifies the subfolder takes precedence. If you have rules with different security levels (one set to disallow and the other set to unrestricted), disallowed takes precedence.
Update Group Policy to configure rules
Your newly configured rules might not take effect immediately. That's because Group Policy must be updated before they apply. You can force a policy update by typing gpupdate at the command line. This command takes the place of the old secedit command that was used to refresh policy in Windows 2000.
Use restriction policies wisely
Software restriction policy is a new weapon in your arsenal for protecting your Windows XP computer from dangerous or unauthorized code. However, before you jump in and embrace this new feature, you need to take time to understand how it works, and realize that it is not a replacement for—but rather, a supplement to—other control mechanisms such as user access rights, antivirus programs, etc. Using restriction policies in conjunction with these can add another layer of defense to your XP security strategy.
Debra Littlejohn Shinder, MCSE, MVP is a technology consultant, trainer, and writer who has authored a number of books on computer operating systems, networking, and security. Deb is a tech editor, developmental editor, and contributor to over 20 additional books on subjects such as the Windows 2000 and Windows 2003 MCSE exams, CompTIA Security+ exam, and TruSecure's ICSA certification.