Control Application Execution with SRP

Users constantly download and run applications they shouldn't, which can result in malware being installed on an organization's network. It's surprisingly difficult to control what users install and execute on their PCs in a Windows desktop world. The first part of solving this problem is making sure that users run their desktops with the least amount of privileges possible—that is, not as administrators or power users unless necessary. The second piece of the puzzle is to control what users can execute.

Many third-party solutions provide application whitelisting or blacklisting—that is, creating lists of applications that are allowed (whitelisted) or not allowed (blacklisted) to run—making it difficult for end users to run code with unknown or unwanted little visitors that can cause problems with your network. However, you can use Group Policy's software restriction policy (SRP, aka Safer) feature to control application execution. Although SRP is missing some features of third-party solutions, such as prebuilt catalogs of application signatures to allow or block, it provides nice capabilities that many IT shops haven't yet discovered or fully exploited.

How SRP Works
SRP is supported on Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP. You'll find it in Group Policy Editor (GPE) under either Computer ConfigurationWindows SettingsSecurity Settings, as Figure 1 shows, or User ConfigurationWindows SettingsSecurity Settings. SRP is available on both the local Group Policy Object (GPO) and domain-based GPOs, but on the local GPO it's available only on a per-computer basis. The power of SRPs comes when you deploy them via domain-based GPOs across multiple systems by using Group Policy's built-in targeting mechanisms.

SRP lets you define application restriction rules within a GPO, and those rules are delivered to the client machine via normal Group Policy processing. Windows stores the rules in the registry and checks them each time a process is executed; if a rule is matched, the application is either allowed or denied, depending on whether it's whitelisted or blacklisted. SRPs don't go into effect on already-running applications, even if Group Policy has applied the rules. It takes a restart of the application for a rule to become effective.

Setting Up SRP
The best way to illustrate how to use SRP is with a typical scenario. For example, I have a business user who runs Microsoft Office and some line-of-business applications. I want to control exactly what that user can execute, so I'm going to implement a whitelist with SRP.

As a best practice, you should create your SRP settings in a separate GPO from other policy settings so that you can disable your restrictions quickly if necessary. You'll need to decide whether to apply your restrictions per-computer or per-user. Per-computer application restrictions apply to anyone who logs on to the computer accounts in Active Directory (AD) that receive those restrictions; this option might be appropriate, for example, when using SRPs against terminal servers. Per-user restrictions are targeted toward a given set of user objects in AD and follow those users wherever they log on.

After you decide how to target your policies, the next step is to enable and start configuring your policies. First, start Group Policy Management Console (GPMC) and create your new software restrictions GPO. Right-click the newly created GPO within the Group Policy Objects container in GPMC and choose Edit to bring up GPE, focused on that GPO.

Navigate to the Software Restriction Policies node under Computer Configuration to set per-computer policies or under User Configurations for per-user policies. Right-click the Software Restriction Policies node and choose New Software Restriction Policies. A set of folders and policy items appears in the right-hand pane, which you can see in Figure 1. You might receive a message that a reboot is required before the policies will be enforced (this is true on Server 2008). This message is a bit confusing because you don't need to reboot either the client or server to start receiving these policies.

The first decision with these new items is whether you want to create a whitelist or blacklist. Whitelists create a more secure environment because they deny all code from running except what you explicitly allow. However, whitelists also require more overhead to manage, depending on the number of applications in your environment, how often the list changes, and what methods you use to identify them. For our example, we'll create a whitelist.

Double-click the Security Levels folder in the right-hand pane of GPE. On Windows 2003 and XP, the folder contains two nodes: Disallowed and Unrestricted. Server 2008 and Vista add a third node, Basic User. The Unrestricted node (blacklist mode) has a small check mark, indicating that it's the current default. To enable whitelist mode, double-click the Disallowed node and press the Set as Default button. Confirm the warning that appears, then close the dialog box to continue.

Basic User is a feature added with the release of Vista. In Basic User mode, users who are administrators on their workstations or AD domains have administrative tokens removed from any applications they run on their system. Essentially, they're prohibited from running any applications with administrative credentials. Behind the scenes, SRP modifies the process token on every application launched by the user to add deny permissions to the following security groups:

Think of Basic User as a mechanism for controlling when your administrators are administrators. You might have a set of sensitive computers that contain customer data that administrators occasionally have to log on to. In such cases, you could set Basic User as the default for these computers to prevent users from running applications with their elevated credentials.

Setting SRP Options
Now it's time to set some general options. If you navigate back to the top-level folder within the policy, you'll see three nodes: Enforcement, Designated File Types, and Trusted Publishers. Double-click the Enforcement node to open the Enforcement Properties dialog box that Figure 2 shows. This dialog box lets you control how SRP enforces its rules.

The first option in the dialog box lets you control whether SRP enforces rules against applications or against applications and all of their dependent DLLs. The default, chosen primarily for performance reasons, is to enforce rules against only the calling application. However, if you're concerned about DLLs as possible vectors for attack, you can enable this capability by choosing the All Software Files option.

The lower Enforcement Properties option lets you specify whether SRPs defined in this GPO apply to all users or to all users except members of the local Administrators group. The default is to exclude administrators so that they won't be subjected to the restrictions that have been defined. Keep this as the default unless you really want your administrators to be subjected to the same rules as your regular users.

You define file extensions that SRP considers to be executable types in the Designated File Types node. Initially, you'll see expected file extensions: .exe, .bat, .msi, and so forth. You can add the extensions of other file types you want to control. You don't have to include an extension such as .xls, for example, if you're already creating a rule preventing Microsoft Excel from running.

The third option in the Software Restriction Policies node is Trusted Publishers. This node lets you control aspects of ActiveX controls. You can control whether users can select the publisher of an ActiveX control as a Trusted Publisher. If regular users are free to do so, you end up having no control over which publishers' ActiveX controls are trusted.

Trusted Publishers also lets you control whether Windows checks that certificates are verified for revocation and valid timestamps before installing an ActiveX control that has been signed by a publisher. Depending on how good your legitimate ActiveX publishers are about keeping their certificates up to date, this might not be a good thing to enable.

Rule Types for Controlling Application Execution
Now let's dive into the heart of leveraging SRP—namely, the rules that control actual application execution. SRP has four rule types to work with:

You'll probably use hash or path rules for 99 percent of your needs. Certificate rules let you allow or restrict execution depending on whether the code is signed by a particular publisher. Unfortunately, many legitimate applications don't sign their code, so this approach is of limited use.

Network zone rules let you control Windows Installer files—essentially letting you specify which Internet Explorer zone a user can execute .msi files from. Because most malware doesn't ship with a handy Windows Installer file, this feature is at best marginally useful. But if for some reason you need to restrict .msi installations, this rule is your friend.

That leaves us with hash and path rules. Let's look at how each of these works and how you can use them.

Hash Rules
In our whitelisting scenario, all executables are prevented from running unless we specifically allow them. There are a couple of ways to create rules to allow executables. A hash rule is a way of identifying an application by a unique hash that's generated by SRP. Microsoft initially used MD5 as the default hashing algorithm but changed to support the newer SHA-256 in Vista. When you create a hash rule on Server 2008 or Vista, Windows stores both versions of the hash for backward compatibility.

Using hash rules lets you control applications regardless of what users do to circumvent your controls. This means hash rules are probably more useful in blacklist scenarios. Let's say, for example, that you want to prevent a user from running Solitaire (sol.exe) on XP. You'll create the new hash rule in GPE. Right-click the Additional Rules node in the right-hand pane and choose New Hash Rule. In the New Hash Rule dialog box, click Browse and browse to C:WindowsSystem32sol.exe, then select OK. As Figure 3 shows, you can now set the security level to Disallowed to prevent users from running the application.

Even if users move sol.exe or rename the executable, the hash rule ensures that the restriction you put in place is maintained. Hash rules are useful for applications that don't change often; however, when the application changes due to an update or patch, its hash value changes and you have to re-do your hash rule. Note that when you specify the executable to control, you should use the version of the application that is specific to your target machines. For example, if you want to restrict Solitaire on XP SP3, you should browse to the version of the executable running on an XP SP3 machine to let SRP calculate the hash.

Path Rules
Path rules are the most useful and powerful of the four SRP rule types. As the name implies, you can specify a path to allow or disallow (or set to Basic User) for execution, and all applications within that path are put under the control of SRP. Creating a path rule is as simple as right-clicking the Additional Rules folder within GPE and choosing New Path Rule, then entering the path on which you wish to create a rule.

The power in path rules is that they can take many forms. For example, a path rule could be something as simple as

Sol.exe or Sol.* or S*.* 

which would prevent users from executing sol.exe, and executables named Sol with any file extension, and any program within the Designated File Types that starts with s. Of course, a path rule can contain an actual path, such as C:Program FilesMicrosoft Office. In this example, all applications within the Microsoft Office folder, including child folders, would be subject to the rule. You can also use UNC paths within path rules. So you could say that only apps found in \MyServerApps are allowed to run. Note that a path rule of \MyServerApps gets resolved to any representation of that same path (e.g., \10.5.1.1Apps or P: where P is mapped to \MyServerApps).

Finally, and perhaps most powerfully, you can create registry path rules. You don't always know where a particular application is installed. For instance, by default Yahoo! Messenger installs under C:Program FilesYahoo!Messenger, but a user could choose a different location to install it. How do you create a rule that covers any place an application might be installed? That's where registry path rules come into play.

A registry path rule is a reference to a location in the registry that points to a file system path. In our example, when Messenger is installed, it creates a registry value under HKEY_LOCAL_MACHINESOFTWAREYahooEssentials called MainDir, which contains the path to where Messenger is installed. You would create a registry path rule to prevent Yahoo! Messenger from running the same way you create other path rules; Figure 4 shows what it would look like.

Note that the registry path is entered all the way to the value that contains the file path you want to restrict and must be surrounded by the percent (%) character. In the registry, that value shows up as C:Program FilesYahoo! When the path rule is evaluated, SRP looks in the registry to find the path to Messenger, and controls all applications under that path.

Another great use for registry path rules is for preventing execution of code that a user has downloaded as an attachment or from a web browser. For example, let's say you want to prevent users from running apps within Internet Explorer without first saving the file. When a user clicks Open on the download dialog box, IE uses the path to the temporary download location within the registry under HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsCachePathsDirectory. If you create a registry path rule to this location and set it to Disallowed, no application type that's in your Designated File Types list can execute from that Open prompt.

Microsoft's Pre-Created Path Rules
When you first create a new SRP within a GPO, you'll notice that Windows automatically creates registry path rules under the Additional Rules node within GPE. These pre-created registry path rules set all applications within C:Windows and C:Program Files (or on whatever path these well-known folders exist) to be unrestricted. I think Microsoft did this to ensure that when you first set up an SRP whitelist, you don't shoot yourself in the foot and prevent key OS components from running correctly.

However, you do need to be aware of these pre-built rules because if you're trying to create a true whitelist, you might not want to allow all programs within C:Windows and C:Program Files to execute. Make sure you test thoroughly if you decide to remove these predefined rules. In fact, if you do want to modify them, I recommend removing only the Program Files rule and leaving the C:Windows rule in place to ensure no applications that are key to the OS's proper functioning are prevented from running.

SRP Interaction If you define SRPs across multiple GPOs, you need to know how they interact. For general options such as whether you're in whitelist or blacklist mode, what file types are in use, trusted publisher settings, and so forth, the effective setting is the one that's processed last when Group Policy processing runs on the client. However, rules are essentially merged. This situation can get tricky because you might have a path rule and a hash rule that contradict each other. In this case, the most specific rule wins.

For example, if you have a hash rule that prevents C:Windowsregedit.exe from running and a path rule that allows everything in C:Windows to run, the hash rule wins because it's more specific—it points to a specific file. Thus, regedit.exe won't run even though everything else in C:Windows will. The bottom line is you should try to avoid having overlapping rules across multiple GPOs.

Give SRP a Spin
SRP provides a powerful mechanism to control application execution on Windows systems without costly third-party solutions. It requires a bit of work, and it's not foolproof, but you can get creative with path rules and even hash and certificate rules to create an environment where your users have access to and can execute primarily code that you know is good. I encourage everyone out there struggling to rein in their users' habits of downloading and running untested code to give SRP a spin and see if they can make their environment safer.