Restricting Software Access and Protecting Computers

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Although a business might use a set of programs that it knows and trusts, and might train its administrators and Help Desk personnel to support those programs, administrators lose control as soon as users begin running unknown code. The increasing role of the Internet in business puts your network at a greater risk than ever before.

Such user-installed programs can conflict with other installed programs, change critical configuration data, or introduce a virus. Users often cannot make safe or informed choices about what software to run because viruses intentionally conceal the malicious purpose of the program. Also, the problems that are associated with running unknown code can increase support costs substantially because they lead to more system maintenance, more help desk time, and lost user productivity.

Software restriction policies, new with Windows XP and Windows Server 2003, provide a policy-driven mechanism that enables you to identify the programs that are running on computers in your domain, and to control their ability to run. By using software restriction policies, you can:

• Control what programs run on your system. For example, you can apply a rule that does not allow certain file types to run in the mail attachment directory of your e-mail program if you are concerned about users receiving viruses through e-mail.

• Run only digitally signed scripts.

• Allow users to run only specific files on multiuser computers. For example, if you have multiple users who use a single computer, you can set up software restriction policies and Access Control List settings so that users cannot make changes to computers.

• Decide who can add trusted publishers to a computer.

• Control whether software restriction policies affect all users or only certain users who use a computer.

• Prevent any files from running on a local computer. For example, if you are aware of a known virus, you can disallow a hash of that virus so that the computers in your domain cannot run that program.

A software restriction policy consists of a rule, or set of rules, that determines what programs are allowed to run, and any exceptions to the rule. Use the Group Policy Object Editor to create software restriction policies. Go to the User or Computer configuration, as appropriate. Under Windows Settings, click Software Restriction Policies. Here you can configure the parameters for Security Levels, set Additional Rules, specify Designated File Types Properties, and identify Trusted PublishersProperties.

The purpose of a rule is to identify one or more software applications, and to specify whether the application is allowed to run. Creating rules is mainly identifying software that is an exception to the default rule. You can include descriptive text with each rule to help communicate why the rule was created. A software restriction policy supports four rules to identify software.

Hash rule

A cryptographic fingerprint of the file, also called a message digest. When you create a hash rule for a program, Software Restriction Policies calculates a hash of the program, and then stores the hash securely. When a user tries to open a program, a hash of the program is compared to existing hash rules for Software Restriction Policies. The hash of a program is always the same, regardless of the location of the program on the user’s computer. However, if a program is altered in any way (by applying a hotfix, for example), its hash also changes, and it no longer matches the hash in the Software Restriction Policies hash rule.

For example, you can create a hash rule, and then set the security level to Disallowed to prevent users from running a certain file. A file can be renamed or moved to another folder and still result in the same hash. However, if any changes are made to the file itself, they also change its hash value and allow it to bypass restrictions.

Certificate rule

A software publisher certificate used to digitally sign a file. For example, a company can require that all scripts and Microsoft® ActiveX® controls be signed with a particular set of publisher certificates. Certificates that are used in a certificate rule can be issued from a commercial Certification Authority (CA) such as VeriSign, a Windows 2000 or Windows Server 2003 public key infrastructure (PKI), or by a self-signed certificate. Certificate rules are a strong means to identify software because the certificate matches the files, regardless of name or location, by using signed hashes that are contained in the signature of the signed file.

Path rule

The local or universal naming convention (UNC) path to where the file is stored. Path rules can include the following:

• Environment variables. Path rules are evaluated in the client environment. Therefore, using an environment variable, such as %Windir%, allows a rule to adapt to a user’s environment.

• Wildcard characters such as and asterisk (*) or question mark (?). By including a wildcard character, a rule can match all files of the specified type. For example, a rule such as *.vbs matches all Microsoft® Visual Basic® script files.

• Registry paths. You can create a path rule that looks up these registry keys for applications that store paths to their installation folders or application directories in the system registry. The registry path is formatted as follows:

  %[Registry Subtree (Hive) Name]\[Registry Key Name]\[Registry Entry (Value) Name]%

  Note

  • A registry path rule suffix cannot contain a backslash (\) character immediately following the last percent sign (%) in the rule.

The following conditions apply:

1. The registry path must be enclosed by percent signs (%).

2. The registry setting must be a REG_SZ or REG_EXPAND_SZ type. If the registry value contains environment variables, these will be expanded when the policy is evaluated.

3. Do not use HKLM as an abbreviation for HKEY_LOCAL_MACHINE, or HKCU as an abbreviation for HKEY_CURRENT_USER.

4. A registry path rule can also include a suffix path.

   For example, you can use:

   %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Cache%OLK*

   Note

   • When you set a path rule, verify the Access Control List (ACL) entries on the path. If users have Write access to a path, they can modify its contents. For example, if you allow Write access to C:\Program Files, any power user on the computer can copy software to the Program Files folder.

Zone rule

An Internet zone rule identifies software by the Microsoft® Internet Explorer zone from which it is downloaded. These zones are: Internet, Intranet, Restricted Sites, Trusted Sites, and My Computer. This rule applies only to Windows Installer (.msi) packages. It does not apply to software that is downloaded by using Internet Explorer.

When a user tries to install a piece of code, Windows Installer queries the software restriction policy to determine the level at which the code is allowed to run. Software restriction policies integrate with the operating system and common scripting runtimes to control the running of software, not just to hide access to applications by removing them from the Start menu or to hide the Run command. Software restriction policies go beyond this by removing the common access points for software.

Essentially, software restriction policies protect against the various Trojan horse and worm viruses that propagate through e-mail and over the Internet. Software restriction policies are a powerful way to identify software so that it can be classified as Unrestricted or Disallowed. After you identify programs, you can apply a policy to either restrict the software or to let it run.

Table 8.7 shows some recommended situations for applying available software restriction policy rules.

Table 8.7   Situations for Applying Each Rule

The following guidelines can help you use software restriction policies effectively:

Create a separate GPO for software restriction policies   When you create a separate GPO for your software restriction policy settings, you can turn them off in an emergency without affecting the rest of your security or other settings.

Never modify the default domain policy   When you do not edit the default domain policy, you can always reapply it.

Never link to a software restriction policy in another domain   Linking to a GPO in another domain can result in poor performance, or it might not work at all. This is true for any GPO, not just for software restriction policies in a GPO.

Test your software restriction policy first   Typographical errors in rules can result in a software restriction policy that does not perform as you expect. Be sure to test your policy on a test computer first.

Turn off a software restriction policy while editing it   When you edit a software restriction policy, each change you make updates the GPO. If a computer tries to synchronize Group Policy settings during an editing session, the user might receive the software restriction policy before you finish editing it. If this happens, the user’s computer might be adversely affected.

Verify that trusted virus scanners are not restricted   Most antivirus software has a real-time scanner program that starts when the user logs in. This program scans all files that are accessible by the user to locate possible virus contamination. Make sure that your rules allow your virus-scanning programs to run. Software restriction policies are not a replacement for antivirus software.

Filter user policies based on membership in security groups   You can decide which users do not have a Group Policy object applied to them by denying them the Apply Group Policy or Read permissions on that policy. You require both of these permissions to apply Group Policy.

Use software restriction policies in conjunction with access control settings   Prepare carefully if using Disallowed as the default setting. Many applications start other applications to perform certain tasks. Verify that all major tasks in your applications are covered by your rules. If your computer needs to run logon scripts, make sure that you have created a path rule that allows them to run.

Restart in Safe Mode if you experience problems with applied policies   Software restriction policies do not apply in Safe Mode. If you accidentally lock down a workstation by applying software restriction policies, restart in Safe Mode, log on as a local administrator, modify the policy, run Gpupdate.exe, restart the computer, and then log on the usual way.

Always test policy on a test computer before applying it to any other computers   Do not apply rules at the Disallow level without the proper testing. Restrictions on certain files can seriously affect the operation of your computer or network.

Rules are evaluated in a specific order. If two rules are similar or conflict, the more restrictive rule takes precedence, and the rules that more specifically match a program take precedence over rules that loosely match a program. In the case of multiple matching path rules, the most specific matching rule takes precedence. Because each rule has an associated GUID, two identical rules have two GUIDs.

Note

• Environment variables are not protected by Discretionary Access Control Lists (DACLs). Therefore, if users can start a command prompt, they can redefine an environment variable to a path of their choosing.

The overall rule precedence is as follows:

1. Hash rule

2. Certificate rule

3. Path rule

4. Internet zone rule

5. Default rule

When multiple path rules match, the most specific matching rule has precedence. The following is a set of paths, listed from highest precedence (a more specific match) to lowest precedence (a more general match):

• Drive:\Folder1\Folder2\FileName.Extension

• Drive:\Folder1\Folder2\*.Extension

• *.Extension

• Drive:\Folder1\Folder2\

• Drive:\Folder1\