Software Restriction Policies Technical Overview

Applies To: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, Windows 8

This topic describes software restriction policies, when and how to use the feature, what changes have been implemented in past releases, and provides links to additional resources to help you create and deploy software restriction policies beginning with Windows Server 2008 and Windows Vista.

Introduction

Software restriction policies provide administrators with a Group Policy-driven mechanism to identify software and control its ability to run on the local computer. These policies can be used to protect computers running Microsoft Windows operating systems (beginning with Windows Server 2003 and Windows XP Professional) against known conflicts and safeguard the computers against security threats such as malicious viruses and Trojan horse programs. You can also use software restriction policies to create a highly restricted configuration for computers, in which you allow only specifically identified applications to run. Software restriction policies are integrated with Microsoft Active Directory and Group Policy. You can also create software restriction policies on stand-alone computers.

Software restriction policies are trust policies, which are regulations set by an administrator to restrict scripts and other code that is not fully trusted from running. The Software Restriction Policies extension to the Local Group Policy Editor provides a single user interface through which the settings for restricting the use of applications can be managed on the local computer or throughout a domain.

Procedures

• Administer Software Restriction Policies

  • Determine Allow-Deny List and Application Inventory for Software Restriction Policies

  • Work with Software Restriction Policies Rules

  • Use Software Restriction Policies to Help Protect Your Computer Against an Email Virus

• Troubleshoot Software Restriction Policies

Software restriction policy usage scenarios

Business users collaborate by using e-mail, instant messaging, and peer-to-peer applications. As these collaborations increase, especially with the use of the Internet in business computing, so do the threats from malicious code, such as worms, viruses, and malicious user or attacker threats.

Users might receive hostile code in many forms, ranging from native Windows executable files (.exe files), to macros in documents (such as .doc files), to scripts (such as .vbs files). Malicious users or attackers often use social engineering methods to get users to run code containing viruses and worms. (Social engineering is a term for tricking people into revealing their password or some form of security information.) If such code is activated, it can generate denial-of-service attacks on the network, send sensitive or private data to the Internet, put the security of the computer at risk, or damage the contents of the hard disk drive.

IT organizations and users must be able to determine which software is safe to run and which is not. With the large numbers and forms that hostile code can take, this becomes a difficult task.

To help protect their network computers from both hostile code and unknown or unsupported software, organizations can implement software restriction policies as part of their overall security strategy.

Administrators can use software restriction policies for the following tasks:

• Define what is trusted code

• Design a flexible Group Policy for regulating scripts, executable files, and ActiveX controls

Software restriction policies are enforced by the operating system and by applications (such as scripting applications) that comply with software restriction policies.

Specifically, administrators can use software restriction policies for the following purposes:

• Specify which software (executable files) can run on client computers

• Prevent users from running specific programs on shared computers

• Specify who can add trusted publishers to client computers

• Set the scope of the software restriction policies (specify whether policies affect all users or a subset of users on client computers)

• Prevent executable files from running on the local computer, organizational unit (OU), site, or domain. This would be appropriate in cases when you are not using software restriction policies to address potential issues with malicious users.

Differences and changes in functionality

There are no changes in functionality in SRP for Windows Server 2012 and Windows 8.

Supported versions

Software Restriction Policies can only be configured on and applied to computers running at least Windows Server 2003, including Windows Server 2012, and at least Windows XP, including Windows 8.

Comparing application control functions in Software Restriction Policies and AppLocker

The following table compares the features and functions of the Software Restriction Policies (SRP) feature and AppLocker.

System requirements

Software restriction policies can only be configured on and applied to computers running at least Windows Server 2003, and at least Windows XP. Group Policy is required to distribute Group Policy Objects that contain software restriction policies.

Software restriction policies components and architecture

Software restriction policies provide a mechanism for the operating system and applications compliant with software restriction policies to restrict the runtime execution of software programs.

At a high level, software restriction policies consist of the following components:

• Software restriction policies API. The Application Programming Interfaces (APIs) are used to create and configure the rules that constitute the software restriction policy. There also are software restriction policies APIs for querying, processing, and enforcing software restriction policies.

• A software restriction policies management tool. This consists of the Software Restriction Policies extension of the Local Group Policy Object Editor snap-in, which administrators use to create and edit the software restriction policies.

• A set of operating system APIs and applications that call the software restriction policies APIs to provide enforcement of the software restriction policies at runtime.

• Active Directory and Group Policy. Software restriction policies depend on the Group Policy infrastructure to propagate the software restriction policies from the Active Directory to the appropriate clients, and for scoping and filtering the application of these policies to the appropriate target computers.

• Authenticode and WinVerify Trust APIs which are used to process signed executable files.

• Event Viewer. The functions used by software restriction policies log events to the Event Viewer logs.

• Resultant Set of Policies (RSoP), which can aid in the diagnosing of the effective policy that will be applied to a client.

For more information about SRP architecture, how SRP manages rules, processes and interactions, see How Software Restriction Policies Work in the Windows Server 2003 Technical Library.

Best practices

Do not modify the default domain policy.

• If you do not edit the default domain policy, you always have the option of reapplying the default domain policy if something goes wrong with your customized domain policy.

Create a separate Group Policy Object for software restriction policies.

• If you create a separate Group Policy Object (GPO) for software restriction policies, you can disable software restriction policies in an emergency without disabling the rest of your domain policy.

If you experience problems with applied policy settings, restart Windows in Safe Mode.

• Software restriction policies do not apply when Windows is started in Safe Mode. If you accidentally lock down a workstation with software restriction policies, restart the computer in Safe Mode, log on as a local administrator, modify the policy, run gpupdate, restart the computer, and then log on normally.

Use caution when defining a default setting of Disallowed.

• When you define a default setting of Disallowed, all software is disallowed except for software that has been explicitly allowed. Any file that you want to open has to have a software restriction policies rule that allows it to open.

• To protect administrators from locking themselves out of the system, when the default security level is set to Disallowed, four registry path rules are automatically created. You can delete or modify these registry path rules; however, this is not recommended.

For best security, use access control lists in conjunction with software restriction policies.

• Users might try to circumvent software restriction policies by renaming or moving disallowed files or by overwriting unrestricted files. As a result, it is recommended that you use access control lists (ACLs) to deny users the access necessary to perform these tasks.

Test new policy settings thoroughly in test environments before applying the policy settings to your domain.

• New policy settings might act differently than originally expected. Testing diminishes the chance of encountering a problem when you deploy policy settings across your network.

• You can set up a test domain, separate from your organization's domain, in which to test new policy settings. You can also test the policy settings by creating a test GPO and linking it to a test organizational unit. When you have thoroughly tested the policy settings with test users, you can link the test GPO to your domain.

• Do not set programs or files to Disallowed without testing to see what the effect may be. Restrictions on certain files can seriously affect the operation of your computer or network.

• Information that is entered incorrectly or typing mistakes can result in a policy setting that does not perform as expected. Testing new policy settings before applying them can prevent unexpected behavior.

Filter user policy settings based on membership in security groups.

• You can specify users or groups for which you do not want a policy setting to apply by clearing the Apply Group Policy and Read check boxes, which are located on the Security tab of the properties dialog box for the GPO.

• When the Read permission is denied, the policy setting is not downloaded by the computer. As a result, less bandwidth is consumed by downloading unnecessary policy settings, which enables the network to function more quickly. To deny the Read permission, select Deny for the Read check box, which is located on the Security tab of the properties dialog box for the GPO.

Do not link to a GPO in another domain or site.

• Linking to a GPO in another domain or site can result in poor performance.

Additional resources