11.2 Software restriction policies

Software restriction policies allow code to be classified as either trusted or untrusted. Trusted code can be executed; untrusted code cannot. Software Restriction Policies are a powerful mechanism: No code stored on your XP Professional or Windows Server 2003 system can hide from SAFER policies—no matter where that code comes from and no matter who or what (a user, a machine, or a service) executes it. SRPs apply to any piece of code, for example, scripting code, an executable, or a Dynamic Link Library (DLL). There a couple of exceptions to this rule: SRPs do not apply to drivers or other kernel mode software, any program that runs in the security context of the local system account and macros defined in Microsoft Office 2000 or Office XP documents.

You can use SAFER policies, for example, to prohibit an administrator from starting a Telnet session from a particular server, restrict user access to Minesweeper, or prohibit the execution of ActiveX controls that Microsoft has not signed. In large environments, such as those of terminal services Application Service Provider (ASP), you can use SAFER policies to limit the applications available to different users.

11.2.1 Managing, distributing, and enforcing SRP settings

From a management, distribution, and enforcement point of view, SAFER is tightly integrated with Windows Group Policy Object (GPO) technology, introduced in Windows 2000. To enforce Software Restriction Policies, administrators need to configure the corresponding GPO settings. Because enforcement of the SAFER settings requires the appropriate GPO client-side extension, you cannot enforce them on earlier servers and clients. They will simply ignore the SAFER policy settings.

To define a Software Restriction Policy, you first need to set one of two default security levels: Unrestricted (meaning an account can run any piece of code if it has the appropriate access rights) or Disallowed (meaning an account cannot run any code, no matter what its access rights are). If you are an administrator who knows little about the software that your users run, I recommend that you choose the Disallowed security level.

Security levels are defined in the “Security Levels” GPO container, located in the Windows Settings\Security Settings\Software Restriction Policies GPO containers (see Figure 11.2). If you are trying to define Software Restriction Policies for a particular GPO for the first time, this container will not show up. Instead, Windows displays a warning message “No Software Restriction Policies Defined.” To make the container visible, right- click the “Software Restriction Policies” container and select “Create New Policies.” The default security level shows a black checkbox on its icon. In the example in Figure 11.2, the default security level is set to “Disallowed.”

After you set the default security level, you can create additional “rules” to refine and set exceptions to the default security level. A software restriction policy rule basically identifies a piece of software. If the default security level is set to “unrestricted,” all additional rules will identify code that cannot be executed (is disallowed). If the default security level is set to “disallowed,” additional rules identify code that is allowed to execute.

Pieces of software can be identified using one of the following four rules:

1. A hash rule identifies code based on its hash thumbprint.

2. A certificate rule identifies code based on the software signing certificate that was used to sign the code.

3. A path rule uses the file system path to the folder where the code is stored for code identification.

4. A zone rule identifies code using the Internet zone of the Web site from which the code was downloaded.

You create rules by right-clicking the “Additional Rules” container (see Figure 11.2) and selecting “New Certificate Rule…” or any of the other three rules. Figure 11.3 shows how a hash rule for the Solitaire executable (Sol.exe) is defined. When the program’s executable has been selected, SAFER will automatically calculate the file hash and fill in its file properties.

Figure 11.2: Setting the default security level.

Figure 11.3: Creating a hash rule for the Solitaire executable.

11.2.2 Fine-tuning SRP application

In addition to the definition of a default security level and exceptions to this default level, SAFER also allows you to specify the file types that are subject to a particular software restriction policy, and to set special enforcement and trusted publisher rules. This is set from the “Enforcement,” “Designated File Types,” and “Trusted Publishers” GPO entries located in the “Software Restriction Policies” container.

By default, any SRP always applies to executables (*.EXE), Dynamic Link Libraries (*.DLL), and Visual Basic Scripts (*.VBS). In addition to this, the “Designated File Types” SRP property allows you to add or remove other file-type extensions. If you open up the “Designated File Types” dialog box for the first time (as illustrated in Figure 11.4), you will notice that—by default—it consists of a list of file types, ranging from batch files(*.BAT) to registry files (*.REG).

Figure 11.4: Setting SRP- designated file-type properties.

The additional Enforcement settings allow you to exclude dynamic link libraries (DLLs) and local administrators from the software restriction policies. Excluding DLLs from the SRP rules may be an interesting option if the default rule is set to “disallowed.” If in this setup you want to give users access to a particular program, you will have to define plenty of SRP exception rules. Remember that SRP rules apply not only to program executables but also to DLLs.

The Trusted Publishers settings allow you to define who can add certificates to the “Trusted Publishers” certificate container and how a code signing certificate is checked for revocation. The Trusted Publishers certificate container is a special certificate store container that holds the certificates of all trusted code signing entities. Accounts that are allowed to add certificates to this container indirectly decide which code is considered trustworthy on a user’s machine.

11.2.3 The rules of the SRP game

As with any GPO setting, Software Restriction Policies can be configured for users and machines, at different levels of the AD hierarchy (domain, OU), and for AD sites. This means that you may end up with multiple SRP rules linked to the same piece of code or program. A rule of thumb to decide which rule will be applied is that “higher-quality” SRPs always take precedence over “lower-quality” SRPs. This means that a hash rule (which can match only a single program) will always have precedence over a path rule (which can match all programs contained in the same file system folder). This rule of thumb brings up the following order of precedence: first hash rules, then certificate rules, then path rules, and finally zone rules. If two rules have the same quality level, the most restrictive rule will apply. The latter can occur when, for example, two path rules point to the same program.

Let’s illustrate this with the example given in Figure 11.5. In this example, a user named David Jagger is contained in the organizational unit (OU), “Engineering.” The computer that David Jagger uses to log in to the domain is contained in the “user desktops” OU. Both the user and the computer account are defined in the “Europe” domain. In the example, the administrator of the Engineering OU wants to prohibit the members of the Engineering department from running “Solitaire” (“sol.exe”). The following sol.exe-related SRPs have been defined:

• The Europe domain has a user and computer SRP rule defined in the “European Policies” GPO. The user SRP rule allows all programs located in “%WINDIR%\System32” to be executed. The computer SRP allows the Solitaire program to run based on the “%WINDIR%\System32\sol.exe” path rule.

• The “Engineering” OU has an SRP rule defined in the “Engineering” GPO. This SRP prohibits users to run Solitaire based on a hash rule.

• The “user desktops” OU has two SRP rules defined in the “user desk- tops” GPO. The first SRP is a path rule that allows all programs in “%WINDIR%” to run. The second SRP prohibits Solitaire to run through the “%WINDIR%\System32\sol.exe” path rule.

  
  Figure 11.5: Sample SRP rule scenario.

What will happen if user David Jagger tries to run Solitaire? To answer this question we first must gather all SRP rules applicable to the user, its machine, and the Solitaire program. (All applicable SRP rules are listed in Figure 11.5.) Then we must classify these rules in order of precedence. Remember that the rule with the highest quality has precedence over all the others. In the scenario in Figure 11.5, the hash rule for sol.exe clearly has the highest precedence. As a consequence, David Jagger will not be able to run Solitaire. Instead, the system displays an error message stating “Windows cannot open this program because it has been prevented by a software restriction policy. For more information, open Event Viewer or contact your administrator.”

The example in Figure 11.5 shows that a path rule has a lower precedence than a hash rule. Also, the path rules for “%WINDIR%/system32/ sol.exe” have higher precedence then the path rules for “%WINDIR%/ system32” and for “%WINDIR%.” This is because the “%WINDIR%/ system32/sol.exe” path points to a single file—the “%WINDIR%” path points to all files contained in %WINDIR%. Finally, you may point out that even though the two path rules for “%WINDIR%/system32/sol.exe” have the same quality level, the one that disallows Solitaire to run has the highest precedence—because it is the most restrictive SRP.

SRP Event Logging Microsoft supports two ways to log SRP-related events. SRP- related events are automatically logged in the Event Viewer’s System event log with an event source of “Software Restriction Policy.” You can enable advanced SRP logging to a separate text file by setting the following registry value (REG_DWORD): HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers\ LogFileName. To log to a file named srp.txt you can use the following command line:

reg.exe add "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\ Safer\CodeIdentifiers" /v LogFileName /d srp.txt