Implementing software restriction policies

I have found through experience that one of the best ways that you can minimize the number of calls that your help desk receives is to keep workstations in a pristine state. To put it bluntly, the more that users tamper with settings, install their own software, and the like, the more likely it is that something is going to break. While a properly configured Windows XP workstation shouldn't give users much of an opportunity to tamper with anything, users can be sneaky. Over the years I have seen sophisticated users employ all kinds of sneaky tricks to bypass the security on their workstations.

One way that you can combat this problem is through the use of software restriction policies. Software restriction policies are a special group policy object that you can use to prevent users from running unauthorized software. Before I show you how to create a software restriction policy though, there are two things that you need to know about them.

First, they are only effective against computers running Windows XP and Windows Server 2003.

Second, a software restriction policy isn't a catch-all-trap for unauthorized software. Instead, it is designed to provide you with a way of preventing specific applications from running. For example, many years ago I was working at a place in which it seemed that almost every user had the video game Frogger installed on their computer. Software restriction policies didn't exist at the time, but if they had, they would have been a perfect solution to this problem. I could have created a software restriction policy that would have prevented anyone from being able to run the game until I had a chance to clean it off of all the machines.

Creating a software restriction policy

Creating a software restriction policy is simple. To do so, open the Group Policy Editor and navigate through the console tree to Computer Configuration (or User Configuration if you want to apply the policy to the user rather than to the computer) | Windows Settings | Security Settings | Software Restriction Policies. Initially, the Software Restriction Policies container will be completely empty. You must right click on the Software Restriction Policies container and select the New Software Restriction Policy command from the resulting shortcut menu. When you do, you are not actually creating a true software restriction policy. Instead, you are causing the Group Policy Editor to create two additional sub folders beneath the Software Restriction Policies container. The first of these sub folders is called Security Levels. You shouldn't ever have to touch anything in this folder. The Security Levels folder simply defines the security levels that can be applied to a policy that you create. Two security levels are defined by default, Disallowed and Unrestricted. The Disallowed security level is exactly what it sounds like. When it is applied to a software restriction policy, then users or computers that the policy is applied to are not allowed to run the specified application.

The unrestricted policy is not exactly what you might think it is. When the Unrestricted Security Level is applied to a software restriction policy, the specified application is only unrestricted in the sense that the software restriction policy will not interfere with the application's ability to run. Other NTFS or group policy based restrictions can still prevent users or computers from being able to run the application.

Now let's look at the Additional Rules folder. There are a few rules that are predefined by default. These rules are just there so that a policy doesn't accidentally block Windows from running. You can create a new rule by right clicking on the Additional Rules container and selecting one of the new rule commands from the shortcut menu. There are four different kinds of rules that you can create. Each type of rule has its advantages and disadvantages, and you should choose the rule that is the most appropriate for you own individual situation.

Certificate rules

Certificate rules are typically used to allow or prevent the installation of applications rather than to prevent existing applications from running. You have probably installed applications or even device drivers that are digitally signed by the manufacturer. You can use the certificate used in the digital signature to either allow the application to run or to prevent it from running. In the case of a digitally signed Setup program, a certificate rule could be an effective way of preventing applications from a specific company from being installed. On the flip side, if you want to insure that applications from Microsoft or applications developed in house are always installed, you could create a certificate rule that applies the unrestricted security level to those certificates.

Hash rules

A hash rule is a rule that is based on a mathematical hash of a specific file. To see how this works, let's go back to my earlier example of wanting to prevent Frogger from running. I could create a hash of the frogger.exe file, assign the Disallowed security level to it, and Frogger would not be able to run.

Hash rules have their good points and bad points. On the upside, there is no easy way for an application to hide from a hash rule. Renaming or moving an application does not change its hash, and therefore the rule will still apply to the application. On the other hand if the user were to upgrade to a new version of the application, the hash rule would no longer apply even if the filename remained the same. For that matter, a user could use a hex editor to change one byte in the file and it would render the hash rule useless. Fortunately, there aren't a lot of users who know how to use hex editors.

Internet zone rules

Internet zone rules offer an excellent defense against spyware. We have all seen malicious Web sites that use scripts to do things like change your browser's home page, install a bunch of entries onto your favorites list, or even install Trojans on to your machine.

Internet zone rules can help with this by telling the machine that unless a Web site is in a trusted zone that it is not allowed to run scripts on your workstations. Of course, no Web sites are trusted by default and some Web sites won't work right if they can't run scripts, so you might have to experiment with this one.

Path rules

The final rule type is a path rule. A path rule allows you to block a program from running based on its path. For example, you could block anything in the C:\Program Files\Microsoft Games folder from running. The problem with path rules is that a user can easily circumvent them by moving the blocked application.

Delayed response times

Now that I have explained the various types of rules that you can create, there is one last thing that I want to tell you about software restriction policies. When you create a software restriction policy, you might find that it does not initially appear to work. There are a couple of different things that can cause this. For starters, the policy that you are creating is a group policy element within the Active Directory. As such, it must be replicated to the other domain controllers before it can be effective. It is also subject to the usual group policy hierarchy rules.

Another reason why a software restriction policy may initially appear not to work is because some applications are cached in Windows \Windows\System32\dllcache folder. If a restricted application has been cached to this folder it may still run until the cache entry has expired.

Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at www.brienposey.com.