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 Files\Microsoft 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 \\MyServer\Apps are allowed to run. Note that a path rule of \\MyServer\Apps gets resolved to any representation of that same path (e.g., \\10.5.1.1\Apps or P: where P is mapped to \\MyServer\Apps).
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 Files\Yahoo!\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_MACHINE\SOFTWARE\Yahoo\Essentials 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 Files\Yahoo! 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_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Cache\Paths\Directory. 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:\Windows\regedit.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.
Register
