How Software Restriction Policies Work

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

How Software Restriction Policies Work

In this section

• Software Restriction Policies Architecture

• Software Restriction Policies Overview

• Software Restriction Policies Processes and Interactions

• Related Information

Software restriction policies provide administrators with a policy-driven mechanism for identifying the software programs running on computers in a domain and for controlling the ability of those programs to run.

Deployment based on Active Directory requires Windows Server 2003, and Windows XP Professional clients, specifically:

• Windows Server 2003 with Active Directory installed and dynamic DNS properly configured.

• Windows XP client computers.

• The Group Policy Object Editor and the Software Restriction Policies extension of Group Policy Object Editor.

For Windows XP computers that are not participating in a domain, you can use the Local Security Settings snap-in to access Software Restriction Policies.

Software Restriction Policies 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 (sometimes referred to as Safer) Application Programming Interfaces (APIs), which 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 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. Software restriction policies functions 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.

The following figure shows an example of the Group Policy Object Editor targeted on one of three different Group Policy objects (GPOs) that apply to a workstation. The Group Policy Object Editor is viewing a GPO containing software restriction policies, A1GPO, which is associated with the University domain. When the computer starts or the user logs on, the policies from A1GPO, A2GPO, and A3GPO are downloaded and applied.

Software Restriction Policies, Group Policy and Active Directory

After Group Policy downloads the software restriction policy, the policy is stored in the registry. This policy is processed during the calls to the software restriction policies (Safer) enforcement APIs. For example, when users double-click an executable file (.exe) in Windows Explorer, the enforcement API, SaferIdentifyLevel, is called to determine the rule details that are associated with that executable file. In this example, if the software restriction policy does not indicate that the program is fully trusted, the executable file does not run. ShellExecute calls SaferIdentifyLevel when a non-natively executable file is double-clicked (this is covered only by Designated File Types). For natively-executable files (a portable executable file or PE), CreateProcess calls SaferIdentifyLevel. See “Default Designated File Types,” later in this section for more information.

Software restriction policies consist of the following components.

Software Restriction Policies Components

Component	Description
Software Restriction Policies (Safer) API	This component is an API for creating and manipulating software restriction policies. The functions in this API are used to get and set the rules that constitute a software restriction policy. Safer APIs provide applications that launch programs from external sources the ability to query security policy for approval before an executable file is launched.
Management tools	These components include the Group Policy Object Editor snap-in, the Software Restriction Policies extension, and command line tools. The management tools use the Software Restriction Policies (Safer) APIs to allow the computer administrator to author and edit software restriction policies.
Safer Enforcement APIs	In Windows Server 2003, these components include functions (SaferIdentifyLevel and SaferComputeTokenFromLevel) that the operating system and applications compliant with software restriction policies use to enforce the software restriction policy. These functions can process the set of software restriction policies rules contained in the policy and return the most appropriate rule for a given program.
Operating system APIs and applications	A set of operating system APIs and applications, compliant with software restriction policies, which call into the Safer enforcement functions to provide enforcement of the policy at runtime. These include Microsoft Office Macros, a .DLL loader, Component Object Model (COM), and these APIs: ShellExecute. Performs an operation on a specified file. CreateProcess. Creates a new process and its primary thread. The new process runs the specified executable file in the security context of the calling process.
Microsoft Windows Script Host	Windows Script Host is not a component of Software Restriction Policies; however, it interacts with Software Restriction Policies. Windows Script Host calls into Software Restriction Policies to apply software restriction policies to scripts that are being run. Note that other script engines do not do this. If you want to perform script checking, you can only run script hosts that call software restriction policies. Windows Script Host is a language-independent scripting host for Windows Script compatible scripting engines. It brings simple, powerful, and flexible scripting to the Windows 32-bit platform, enabling you to run scripts from both the Windows desktop and the command prompt.
Windows Installer	Windows Installer (Msiexec) is not a component of Software Restriction Policies, but it also interacts with Software Restriction Policies. Windows Installer calls into Software Restriction Policies to apply software restriction policies to scripts that are being installed. Windows Installer implements the Software Restriction Policies API.
Group Policy	Group Policy is a feature included in Windows XP, Windows 2000, and Windows Server 2003. Software restriction policies use the Group Policy’s Registry.pol files. The Administrative Templates extension of Group Policy saves information in Registry.pol files. These files contain the customized registry settings that you specify (by using Group Policy) to be applied to the computer or user portion of the registry. One Registry.pol file contains registry settings that are specific to the HKEY_LOCAL_MACHINE key; it is stored in the Group Policy Template folder, in the \Machine subfolder. The other Registry.pol file contains registry settings that are specific to the HKEY_CURRENT_USER key; it is stored in the Group Policy Template folder, in the \User subfolder. Software restriction policies do not use a client side extension. Software restriction policies depend on Group Policy to propagate the policy from the Active Directory to the appropriate clients and use the appropriate filtering and scoping.
Event Viewer	Software restriction policies functions log events in the Event log. The SaferRecordEventLogEntry function saves messages to an event log.
Authenticode and WinVerifyTrust	These components are used to process signed executable files. Microsoft Authenticode, which is based on industry standards, enables developers to include information about themselves and their code with their programs through the use of digital signatures. The WinVerifyTrust function performs two actions: signature checking on a specified object and trust verification action.
Windows Management Instrumentation (WMI)	The Software Restriction Policies extension queries the registry policy by using WMI. WMI is a component of the Microsoft Windows operating system and is the Microsoft implementation of Web-Based Enterprise Management (WBEM), which is an industry initiative to develop a standard technology for accessing management information in an enterprise environment. WMI uses the Common Information Model (CIM) industry standard to represent systems, applications, networks, devices, and other managed components. You can use WMI to automate administrative tasks in an enterprise environment.
Resultant Set of Policy (RSoP)	RSoP is a Group Policy feature that aids in diagnosing effective policy settings that will be applied to a client. Software restriction policies provide support for RSoP.
Registry	Software restriction policies are stored in the registry. In HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer or in HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows.

For information about the Software Restriction Policies (Safer) functions, see the topic “Safer” in the Security section of the Microsoft Platform SDK on MSDN.

Software Restriction Policies Overview

A software restriction policy consists of a default rule that defines which programs can run, and a set of exceptions to the default rule.

You can set the default rule, which specifies whether software can run, to either Unrestricted (program can run) or Disallowed (program cannot run). If you set the default rule to Unrestricted, you can also define exceptions to specify a set of programs that are not allowed to run. The Unrestricted default setting is appropriate in an environment with lightly managed clients. For example, you can prevent users from installing a program that conflicts with existing programs by creating a rule to block that program.

For environments that require a more secure method of software control, you should set the default rule to Disallowed and then allow only a specific set of programs to run. If you use the Disallowed default setting, you have to identify all the software that users are permitted to run and create appropriate rules for them. The Disallowed default setting is the preferred default for securing Windows XP clients.

Rules in Software Restriction Policies

Software restriction policies use rules to identify one or more software applications, and to specify whether the software is permitted to run. By creating rules, administrators can identify software that is an exception to the default rule. Each rule can include descriptive text to indicate why the rule was created.

To identify software, software restriction policies support the following rules:

• Hash. A cryptographic fingerprint of the file

• Certificate. A software publisher certificate used to digitally sign a file

• Path. The local or universal naming convention (UNC) path of where the file is stored

• Zone. Internet Zone

Hash Rule

A hash is a cryptographic fingerprint that uniquely identifies a file regardless of its name or where it is accessed. With a hash rule, software can be renamed or moved into another location on a disk, but it will still match the hash rule because the rule is based on a cryptographic calculation involving file contents. Hash rules work effectively in a static environment. If the software in your clients is upgraded frequently, hash rules can become difficult to manage. Whenever a program executable is updated, the hash rule needs to be updated to support the new executable version.

For secure environments using a default level of Disallowed, hash rules are a very secure way to identify applications that you want to allow to run as Unrestricted. For environments using a default level of Unrestricted, hash rules allow you to specifically identify one particular version of an application to disallow.

A hash rule consists of three pieces of data, separated by colons:

• MD5 or SHA-1 hash value

• File length

• Hash algorithm ID

A hash rule uses the following format:

[MD5 or SHA1 hash value]:[file length]:[hash algorithm id]

Files that are digitally signed use the hash value contained in the signature, either SHA-1 or MD5. Files that are not digitally signed use an MD5 hash.

For example, the following hash rule matches a file with a length of 126 bytes and with contents that match the MD5 (denoted by the hash algorithm identifier of 32771) hash of 7bc04acc0d6480af862d22d724c3b049:

7bc04acc0d6480af862d22d724c3b049:126:32771

Certificate Rule

A certificate rule specifies a code-signed software publisher’s certificate. For example, a company can require that all scripts and ActiveX controls be signed with a particular set of publisher certificates. Certificates used in a certificate rule can be issued from a commercial certificate authority (CA) such as VeriSign, a Windows 2000 or Windows Server 2003 Public Key Infrastructure (PKI), or a self-signed certificate.

A certificate rule uses signed hashes contained in the signature of the signed file to match files regardless of name or location. If you want to make exceptions to a certificate rule, you can use a hash rule to identify the exceptions. Certificate rules provide more flexibility than hash rules. By using a certificate rule, you can allow (or deny) multiple applications at once. Certificate rules also allow low maintenance of the software restriction policies rule-set, but they can provide the security of hash rules.

Path Rule

A path rule can specify a folder or fully qualified path to a program. When a path rule specifies a folder, it matches any program contained in that folder and any programs contained in subfolders. Software restriction policies support local and Uniform Naming Convention (UNC) paths.

The administrator must define all directories for launching a specific application in the path rule. For example, if the administrator creates a shortcut on the desktop to launch an application, then in the path rule, the administrator must also grant the user Read access rights to both the executable file and the shortcut paths to run the application. If all the path information necessary for launching the application in the path rule is not defined, it can trigger the Software Restricted warning when the user attempts to run the application.

Environment variables in path rules

You can use environment variables in a path rule. Since path rules are evaluated in the client environment, the ability to use environment variables (for example, %Windir%) allows a rule to adapt to a particular user’s environment.

Note

• Environment variables are not protected by Access Control Lists (ACLs). There are two types of environment variables: Users and System. Users that are able to start a command prompt can redefine the Users environment variable to a different path. The reason for this is that if an administrator uses %Windir% in a path rule, then a user can run Cmd.exe, change the value of %Windir% to a directory where the user’s .exe file is, run his or her .exe file, and then exit that shell or change %Windir% back. It is also possible for a user to make changes programmatically or by using the System Properties page in Control Panel. Only users in the Administrators group have permissions to change the System environment variable.

• If you need to provide enhanced security in your environment, use the registry-based path rules, which is the preferred method. See “Registry Path Rules,” later in this section.

The following examples show instances of applying environment variables to a path rule:

• “%UserProfile%” matches C:\Documents and Settings\User and all subfolders under this directory.

• “%ProgramFiles%\Application” matches C:\Program Files\Application and all subfolders under this directory.

Wildcards in path rules

A path rule can incorporate the ‘?’ and ‘*’ wildcards, allowing rules such as “*.vbs” to match all Visual Basic Script files. The following examples illustrate the use of wildcards:

• “\\DC-??\login$” matches \\DC-01\login$, \\DC-02\login$

• “*\Windows” matches C:\Windows, D:\Windows, E:\Windows

• “c:\win*” matches c:\winnt, c:\windows, c:\windir

Registry path rules

Many applications store paths to their installation folders or application directories in the Windows registry. You can create a path rule to look up these registry keys. For example, some applications can be installed anywhere on the file system. These locations might not be easily identifiable by using specific folder paths, such as C:\Program Files\Microsoft Platform SDK, or environment variables, such as %ProgramFiles%\Microsoft Platform SDK. If the program stores its application directories in the registry, you can create a path rule that uses the value stored in the registry, such as %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PlatformSDK\Directories\Install Dir%. This type of path rule is called a registry path rule. Using registry path rules is a recommended practice because users cannot bypass the path rule by undermining the environment variable expansion.

The registry path format is:

%[Registry Hive]\[Registry Key Name]\[Value Name]%

Note

• A registry path rule suffix must not contain a backslash (\) character immediately after the last percent sign (%) in the rule. The registry hive name must be written out; abbreviations will not work.

The following conditions apply to registry paths rules:

• The registry path must be enclosed in percent signs (%).

• The registry value must be a REG_SZ or REG_EXPAND_SZ. You cannot use HKLM as an abbreviation for HKEY_LOCAL_MACHINE, or HKCU as an abbreviation for HKEY_CURRENT_USER.

• If the registry value contains environment variables, these will be expanded when the policy is evaluated.

• A registry path rule can also contain a suffix path such as %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Cache%OLK*. This registry path rule identifies the folder that Microsoft Outlook XP uses to store attachments before launching them. The attachment folder always starts with the letters “OLK” so the rule uses wildcard matching. For example, this rule matches the following path: C:\Documents and Settings\username\Local Settings\Temporary Internet Files\OLK4.

Note

• When you set a path rule, you should check 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 C:\Program Files, any power user on the computer can copy software into the Program Files folder.

When the default rule is set to Disallowed, there are four registry paths that are setup so the operating system has access to system files for normal operation. These registry path rules are created as a safeguard against locking yourself and all other users out of the system. These registry rules are set to Unrestricted. Only advanced users should consider modifying or deleting these rules. The registry path rule settings are:

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%\*.exe

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\ CurrentVersion\SystemRoot%\System32\*.exe

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

Path rule precedence

When there are multiple matching path rules, the most specific matching rule takes precedence.

The following is a set of paths, from highest precedence (more specific match) to lowest precedence (more general match):

• Drive:\Folder1\Folder2\FileName.Extension

• Drive:\Folder1\Folder2\*.Extension

• *.Extension

• Drive:\Folder1\Folder2\

• Drive:\Folder1\

Zone Rule

A rule can identify software from the Internet Explorer zone from which it is downloaded. These zones are:

• Internet

• Intranet

• Restricted Sites

• Trusted Sites

• My Computer

The current version of the Internet zone rule applies to only Windows Installer (*.msi) packages. This rule does not apply to software downloaded by using Internet Explorer. All other file types affected by zone rules are listed in the table on designated file types that appears under the “Default Designated File Types” heading, later in this section. There is one list of designated file types that is shared by all zone rules.

Note

• Each rule is associated with a globally unique identifier (GUID). An example GUID is {f8c2c158-e1af-4695-bc93-07cbefbdc594}. Two identical rules, for example two Disallowedhash rules on the same program, have a different GUID associated with each. This GUID is stored in the registry along with the rule data.

Rules Precedence

Rules for software restriction policies are evaluated according to 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 ordered list defines the precedence order for the rules from the most specific (hash) to the least specific rule (default):

1. Hash rule

2. Certificate rule

3. Path rule

4. Zone rule

5. Default rule

Policy Enforcement Options

There are two policy enforcement options that influence the behavior of a software restriction policy. The following options define how software restriction policies are applied for all files, including signed files:

• Apply software restriction policies to the following: All files. This option includes dynamic-link libraries (DLLs).

• Apply software restriction policies to the following users: All users except local administrators. This option prevents the software restriction policies from applying to local administrators.

Including DLLs

Most programs consist of an executable file and many supporting DLLs. By default, software restriction policy rules are not enforced on DLLs. Not checking DLLs is the recommended option for most customers for the following reasons:

• Including DLLs degrades system performance because it has to check all libraries linked to the application. For example, if a user runs 10 programs during a logon session, the software restriction policy evaluates each program. When the Apply software restriction policies to the following: All files is selected, the software restriction policy evaluates each DLL load within each program. If each program uses 20 DLLs, this results in 10 executable program checks plus 200 DLL checks, so the software restriction policy must perform 210 evaluations. A program such as Internet Explorer consists of an executable file, iexplore.exe, and many supporting DLLs.

• Setting the default security level to Disallowed forces the system to identify both the main executable file andits supporting DLLs before the .exe file can run, which places added burden on the system.

Note

• To provide the highest assurance possible for the programs running in environments that want the highest assurance possible when running programs, DLL Checking is the recommended option. DLL checking is recommended because while viruses primarily target executable files, some specifically target DLLs. To ensure that a program does not contain a virus, you can use a set of hash rules that identify the executable file and its constituent DLLs.

Excluding Administrators

An administrator might want to disallow programs from running for most users, but allow administrators to run all of them. For example, an administrator might have a shared computer that multiple user’s connect to using terminal server. The administrator might want users to run only specific applications on the computer, but allow members in the local Administrators group to run any program. You can use the Apply software restriction policies to the following users: All users except local administrators enforcement option to do this.

If the software restriction policy is created in a GPO linked to an object in Active Directory, instead of using the Skip Administrators option, consider denying the Apply Group Policy permission on the GPO to the Administrators group. This approach consumes less network traffic 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. In this case, use the Skip Administrators option.

Default Designated File Types

Software restriction policy rules apply automatically to some types of executable files, regardless of their extension type. This includes the following types of files:

• Windows operating system executable files (.exe, .com, .dll)

• Windows scripting files (when processed by Windows Script Host, such as .vbs, and .wsh files)

• Command batch files (when processed by Windows CMD, such as .bat, .cmd)

• Installation packages when processed by Windows Installer (.msi)

You can apply software restriction policies rules to additional file types, even when they are handled by non-Microsoft programs. However, if the other program does not enforce software restriction policies itself, the software restriction policies restrictions will only apply when either Windows Explorer or Internet Explorer is used to open the file. Opening the other program and then opening the executable script from within that program circumvents software restriction policies. To resolve this issue, contact the software provider and request that they enforce software restriction policies when opening executable scripts, or disallow execution of the other scripting host.

The file types are listed in the Designated File Types Properties dialog box. This dialog is accessible in the Group Policy Object Editor, in Computer Configuration\Windows Settings\Security Settings\Software Restriction Policies, under Designated File Types in the details pane. Additional file types to which you want to apply rules can be added to this list. For example, for Perl scripting files you might 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. Note that you can check only the initial script this way; if a Perl script calls another Perl script, there will be no software restriction policies check.

The following table lists what is considered to be executable code. This is in addition to standard program files such as .exe, .dll, and .vbs.

Default Designated File Types

File Extension	File Description
.ade	Microsoft Access Project Extension
.adp	Microsoft Access Project
.bas	Visual Basic Class Module
.bat	Windows Batch File
.chm	Compiled HTML Help File
.cmd	Windows NT Command Script
.com	Application
.cpl	Control Panel extension
.crt	Security Certificate
.exe	Application
.hlp	Windows Help File
.hta	HTML Applications
.inf	Setup Information File
.ins	Internet Communication Settings
.isp	Internet Communication Settings
.lnk1	Shortcut
.mdb	MDB File
.mde	Microsoft Access MDE Database
.msc	Microsoft Common Console Document
.msi	Windows Installer Package
.msp	Windows Installer Patch
.ocx	ActiveX Controls
.pcd	Photo CD Image
.pif	Shortcut to Program
.reg	Registration Entries
.scr	Screen Saver
.shs	Shell Scrap Object
.url	Internet Shortcut (Uniform Resource Locator)
.vb	VB File
.wsc	Windows Script Component

1 If you click a .lnk file (shortcut) in the UI, ShellExecute applies software restriction policies to it if the .lnk extension is included in Designated File Types. Otherwise, ShellExecute runs the target, where software restriction policies get applied in CreateProcess.

If the file type of the shortcut’s (.lnk) target is not an executable file directly, such as a .doc file, and if .doc is included in Designated File Types, software restriction policies rules are applied to the .doc file. If .doc is not included in Designated File Types,ShellExecute runs the handler with specified options (such as running “WinWord filename.doc”). At this point, CreateProcess applies software restriction policies to the application, WinWord, and not to the filename.doc, which was the actual target of the .lnk.

Trusted Publishers

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 trusting a publisher. With certificate rules enabled, software restriction policy will check a certificate revocation list (CRL) to ensure the software’s certificate and signature are valid. This can decrease performance when starting signed programs. The options under the General tab of the Trusted Publishers Properties dialog box. You access this dialog in the Group Policy Object Editor snap-in, by navigating to Computer Configuration\Windows Settings\Security Settings\Software Restriction Policies, anddouble-clicking Trusted Publishers in the details pane.

Note

• If you enable the Trusted Publishers option, you must also explicitly add the certificates of allowed ActiveX publishers to the Trusted Publisher certificate store. Adding the certificates is required to ensure that installation and other operations work properly and to maintain the appropriate system functions. If you don’t add the certificates, ActiveX controls will not install, and some applications which perform signature validation might exhibit unexpected behavior. All trust validations using the default Authenticode policy fail unless the signing certificate is in the Trusted Publishers store. For example, Windows Update automatically validates its own signature and the signatures of downloaded files. The Trusted Publishers restrictions are only recommended for the most restrictive environments.

Default Settings for a Software Restriction Policy

The default settings for a software restriction policy include the following:

• Default Security Level: Unrestricted

• Enforcement options:

  • Apply to Files: All software files except libraries (such as DLLs)

  • Apply to Users: All users

• Additional Rules: none

• Designated File Types: These are defined in the “Default Designated File Types” section, earlier in this document.

• Trusted Publishers:

  • Select Trusted Publishers: End users

  • Publisher certificate revocation checking: Not selected

  • Timestamp certificate revocation checking: Not selected

Example: Applying Software Restriction Policies in a Highly Restricted Environment

In some cases, you might want to manage all of the software that runs on a computer. For example, even when users have insufficient rights to replace system files or files in shared folders such as Program Files, if the user’s have a place on the file system to which they can write, they could copy a program there and start it from that location.

Administrators can create a highly-restricted (locked down) configuration to prevent users from modifying the contents of the Program Files or Windows folders, and allow them to run only software that is installed by the administrator. In this case, you would also need to ensure that users are not administrators on their local computers.

The following policy can help prevent users from running malicious code:

• Default Security Level: Disallowed

• Apply software restriction policies to the following users: All users except administrators

• Path Rules:

  • %WINDIR% Unrestricted

  • %PROGRAMFILES% Unrestricted

This policy disallows all software on the users computer, except software that is installed in the Windows directory, Program Files directory, or their respective subfolders. The policy does not apply to administrators.

If all the programs a user needs are not installed in %WINDIR% or in %PROGRAMFILES%, or there are programs in those folders that the administrator does not want the user to run, the administrator can make additional exceptions as follows:

• Path Rules:

  • %WINDIR%\regedit.exe: Disallowed

  • %WINDIR%\system32\cmd.exe: Disallowed

  • \\CORP_DC_??\scripts: Unrestricted

  • %HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates \InoculateIT\6.0\Path\HOME%: Unrestricted

As a result of these exceptions, the following occurs:

• Both the command prompt (cmd.exe) and the registry editor (regedit.exe) are disallowed.

• An exception is created to allow login scripts to run on the users computer.

• The use of the question mark “?” wildcard allows the rule to match \\CORP_DC_01, \\CORP_DC_02, and others.

• A registry path rule is added that allows the anti-virus software on the computer to run.

Software Restriction Policies Processes and Interactions

This section discusses how software restriction policies are processed and stored, and also explains how software restriction policies are merged.

Software Restriction Policies Processing

Software restriction policy is distributed by using the normal Group Policy process. That is, software restriction policies are saved in Group Policy objects (GPOs), and the management tools use the Group Policy Interfaces (IGroupPolicyObject) to save and load the software restriction policies. GPOs are linked to sites, domains, or organizational units (OUs) in Active Directory. An administrator can use the standard Group Policy mechanisms to apply additional filtering options to a GPO to have it apply to a select set of users or computers within an OU.

When a computer starts up or when a user logs on, the Group Policy engine queries Active Directory for any GPOs that apply to it. It downloads and applies these GPOs in a specific order (local, site, domain, and OU), where the closest OU to the user or computer object is the last GPO applied. If Group Policy fails to download any of the GPOs, the entire process is aborted and no GPOs are applied.

In regard to software restriction policies (also referred to as Safer), Group Policy processing essentially involves downloading a number of Registry.pol files from Active Directory. The Registry.pol files contain the registry keys and values set through the Safer policy APIs. The keys and values of each policy are then copied into the local user’s registry in the HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER registry hive as appropriate. This process is repeated for each GPO that contains a software restriction policy. Group Policy is periodically refreshed: on clients, security policy reapplies every 16 hours regardless of whether policy changes have occurred. If there is a policy change, it applies within 90 minutes of the change. All the policy distribution is handled by the Group Policy infrastructure and not by the software restriction policies extension directly. The Safer Enforcement APIs base their decisions on the effective policy, which is the result of combining the software restriction policies in the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER registry hives.

Software restriction policies do not implement a client side extension to Group Policy.

Group Policy Processing Order

By default, Group Policy is inherited and cumulative, and it affects all computers and users in an Active Directory container. Group Policy objects are processed according to the following order:

• Local Group Policy object. Each computer has one Group Policy object that is stored locally. This processes for both computer and user Group Policy processing. The local GPO can’t be blocked by domain-based GPOs. However, settings in domain GPOs always take precedence because they are processed after the local GPO.

• Site. Any GPOs that have been linked to the site that the computer belongs to are processed next. They are processed in the order specified by the administrator, on the Linked Group Policy Objects tab for the site in the Group Policy Management Console (GPMC). The GPO with the lowest link order is processed last, and therefore has the highest precedence.

• Domain. Multiple domain-linked GPOs are processed in the order specified by the administrator, on the Linked Group Policy Objects tab for the domain in GPMC. The GPO with the lowest link order is processed last, and therefore has the highest precedence.

• Organizational units. GPOs that are linked to the OU that is highest in the Active Directory hierarchy are processed first. Then GPOs that are linked to its child OU are processed, and then any lower child OUs. Finally, the GPOs that are linked to the OU that contains the user or computer are processed.

This processing is subject to the following conditions:

• WMI or security filtering that has been applied to GPOs.

• A domain-based GPO can be enforced by using the Enforce option to ensure that it’s policies cannot be overwritten. Because an Enforced GPO is processed last, no other settings can overwrite the settings in that GPO. If more than one Enforced GPO exist, its possible to set the same setting in each GPO to a different value, in which case, the link order of the GPOs determines which one contains the final settings.

• At any domain or OU, Group Policy inheritance can be selectively designated as Block Inheritance. However, because enforced GPOs are always applied and cannot be blocked, blocking inheritance does not prevent policy from Enforced GPOs from being applied.

Group Policy Refresh Period

By default, Group Policy is processed every 90 minutes plus a randomized offset of up to 30 additional minutes for a total maximum refresh interval of up to 120 minutes. For domain controllers, the default period is every 5 minutes. You can change the default values for computers by using the Group Policy Refresh Interval for Computers Group Policy setting under Administrative Templates in the Default Domain Controllers GPO. For domain controllers, the Group Policy Refresh Interval for Domain Controllers setting controls this default; it is available under Computer Configuration\Administrative Templates\System\Group Policy.

For computers, the Gpupdate command can also be used to trigger a background refresh of Group Policy on demand from the client.

Merging for Multiple Software Restriction Policies

Whenever two or more Group Policy objects apply to a user or computer, the policies are merged. When two or more software restriction policies are merged, the following occurs:

• The GPO with the highest precedence sets the following values:

  • Default Security Level

  • Designated File Types

  • Skip Administrators

  • DLL Checking

• The rules from multiple GPOs are always merged. Thus, all additional rules from all GPOs are preserved.

A software restriction policy can be set for user scope and computer scope. The following semantics are observed when merging user and computer scope:

• The more restrictive default security level is chosen.

• The list of designated file types in the computer policy, if present, is used. If not present, the list of designated file types in the user policy is used.

• The Skip Administrators value is always chosen from the computer policy.

• If DLL checking is enabled in either policy, then it is enabled.

• All the rules between user and computer policies are merged.

Storage of Software Restriction Policies Settings

After a software restriction policy is applied, the software restriction policy configuration is stored in the system registry. The security access control list (ACL) protecting these registry keys allows only members of the Administrators group and the SYSTEM account to change them.

Software restriction policies use these registry keys: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer and HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows.

• CodeIdentifiers.

• Default Level (DWORD). 40000 for Unrestricted, 0 for Disallowed.

• ExecutableTypes (REG_MULTI_SZ). List of extensions for designated file types.

• TransparentEnabled (DWORD). Defines which files to include during rule evaluation. 0 means no enforcement, 1 indicates to exclude DLLs in evaluation, and 2 indicates to include all files in evaluation.

• PolicyScope (DWORD). Defines the scope of users to which this policy applies. 0 applies to all users, and 1 applies to all users except administrators. Note that this value is only valid for HKEY_LOCAL_MACHINE.

• AuthenticodeEnabled (DWORD). Defines if certificate rules should be applied, 0 means disabled, 1 indicates that certificate rules will be applied. Note that this value is only valid for HKEY_LOCAL_MACHINE.

• LogFileName (REG_SZ). An optional registry value that needs to be set manually. This value defines a path to the log file that captures advanced logging. If this value is set, advanced logging is enabled and written to this log file. Note that this value is only valid for HKEY_LOCAL_MACHINE.

• The zero (0) key**.** Indicates a SAFER_LEVELID_DISALLOWED security level. Entries under this key are Disallowed rules.

  • Hashes. All hash rules are defined under this key.

    {GUID}. This is uniquely generated for each Rule defined.

    Description (REG_SZ). This is the administrator-defined description of the rule.

    FriendlyName (REG_SZ). This is the name of the hash.

    HashAlg (REG_DWORD). This is the type of hash that is stored in ItemData. For files that are not digitally signed or are signed with MD5, this value is defined as 0x8003 or CALG_MD5 or (ALG_CLASS_HASH | ALG_TYPE_ANY | ALG_SID_MD5).

    ItemData (REG_BINARY). The actual hash to the file. This value should always be 16 bytes and is generated with a call to CodeAuthzpComputeImageHash().

    ItemSize (REG_QWORD). This is the actual file size of the target file. To evaluate this value, reverse the bytes. For example, if the value data was: 00 0A 01 00 00 00 00 00, the file size would actually be 010a00 or 68,096 bytes.

    LastModified (REG_QWORD). This is the date and time down to seconds of when this entry was last updated. Several utilities exits to extract this name into a readable format however just as the ItemSize data was reversed so should this value.

    SaferFlags (REG_DWORD). Not used and will always be set to zero.

• Path. All Path rules are defined under this key.

  • {GUID}. This is uniquely generated for each Rule defined.

  • Description (REG_SZ). This is an administrator defined description of the rule.

  • ItemData (REG_EXPAND_SZ Or REG_SZ). This is the path to be used for this rule. Note that if the data provided for this value includes any environment variables that must be expanded the value type will be REG_EXPAND_SZ otherwise it will be REG_SZ.

  • LastModified (REG_QWORD). This is the date and time down to seconds of when this entry was last updated. Several utilities exits to extract this name into a readable format however just as the ItemSize data was reversed so should this value.

  • SaferFlags (REG_DWORD). This is not used and will always be set to zero.

• UrlZones. All zone rules are defined under this key.

  • {GUID}. This is uniquely generated for each Rule defined.

  • ItemData (REG_BINARY). Defines the URLZone to which this rule is defined. URL Zones are defined in urlmon.h and are of type enum tagURLZONE. For example if a value of 0x3 appears in this value that evaluates to URLZONE_INTERNET.

  • LastModified (REG_QWORD). This is the date and time down to seconds of when this entry was last updated. Several utilities exits to extract this name into a readable format however just as the ItemSize data was reversed so should this value.

  • SaferFlags (REG_DWORD). This is not used and will always be set to zero.

• 262144. Indicates a SAFER_LEVELID_FULLYTRUSTED security level. Entries under this key are Unrestricted rules.

Certificate Rules

Certificate rules are stored in a separate key in the registry.

Certificate rules for user software restriction policies are stored in this registry key:

• HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\SystemCertificates

Certificate rules for computer software restriction policies are stored in this registry key:

• HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates

Resultant Set of Policy

To obtain information about policy stored in the registry, the Software Restriction Policies extension queries the registry policy by using WMI.

The RSOP_RegistryPolicySetting WMI namespace represents policy data for registry or administrative template extension. Policy settings in an administrative template file (.adm) involve setting values on registry keys that are abstracted by this namespace. Software Restriction Policies also store information in the registry.

To retrieve this registry data, the IwbemServices WMI interface’s ExecQuery method is used to perform a query to retrieve objects from the RSOP_RegistryPolicySetting namespace.

Related Information

The following resources contain additional information that is relevant to this section.

• “How Core Group Policy Works” in the Group Policy Collection.

• “How Group Policy Software Installation Extension Works” in the Group Policy Collection.