If you’ve ever supported a Windows 9x network, you know how difficult it can be to control the software that’s running on the workstations. I can’t count the times over the years when I’ve had to perform routine maintenance or fix a problem on a user’s workstation and found lots of unauthorized software in the process. Personally, I really wouldn’t have a problem with users running whatever applications they want, except that these unauthorized applications fill up the hard disk and change critical configuration files, and they can even contain viruses or Trojan horse software.
Operating systems such as Windows NT, Windows 2000, and Windows XP greatly reduce the number of unauthorized applications because they restrict what a user can do while logged on. However, there are still circumstances in which a user could install an unauthorized application. Windows XP and Windows .NET Server go a step further toward fixing the problem, though. They both support something called software restriction policies. In this Daily Drill Down, I’ll introduce you to software restriction policies and show you how they work.
Rule-based software restrictions
Software restriction policies use rules to restrict software usage. A rule has two main components: the first is the identification of the software that the rule applies to, and the second is the software’s authorization status. For example, suppose that you found an unauthorized copy of Adobe Photoshop on a user’s machine. You could set a rule that tells the machine that Photoshop is disallowed by applying the Disallowed security level. This would prevent Photoshop from running. If you later needed to authorize Photoshop, you could either get rid of the rule completely, or you could set the rule to the Unrestricted security level, which allows the application to execute freely. Unrestricted and Disallowed are the only two authorization choices. Therefore, an application can either be allowed or disallowed; there is no in between.
There are four different types of rules that you can use to restrict or permit an application: hash rules, certificate rules, path rules, and Internet zone rules. I’ll discuss each of these rules in detail later on, but for now, you need to know about rule precedence.
Because you can establish all kinds of different rules, it’s possible to create rules that contradict each other. This is where precedence comes in. The order of precedence determines which rule takes effect when rules contradict each other. The order of precedence means that hash rules always take top priority, followed by certificate rules, path rules, and Internet zone rules. This means that if a certificate rule allowed an application to run but a path rule disallowed the same application, the application would be allowed to run because the certificate rule would take precedence over the path rule.
If you want rules to apply to one machine only, use the Local Security Policy for that workstation. To set rules for all machines on the network, you’d use Group Policies through a Group Policy Object on your Windows .NET Server. To start the Group Policy Editor, click Start | Run and type dsa.msc in the Run dialog box. When you do, you’ll see Active Directory Users And Computers start.
Right-click the domain you want to apply the restrictions to, and select Properties. When the Properties window appears, click the Group Policy tab. Click New to define a new specific software restriction group policy, or click Edit to edit the existing Default Domain Policy. When you click either New or Edit, you’ll see the Group Policy Editor. To find the Software Restriction hive, click Computer Configuration | Windows Settings | Security Settings | Software Restriction Policies, as shown in Figure A.
|You can create software restriction policies for your entire domain.|
After you’ve started the Group Policy Editor and found the proper hive, you can define whatever policy you want. In the sections that follow, I’ll show you how to configure each rule.
Hash rules use a file’s hash to identify the file. A hash is a number that uniquely identifies a file, based on a mathematical calculation. The software restriction policies can calculate a file’s hash by using either the SHA-1 (Secure Hash Algorithm) or the MD5 hash algorithm. You can assign a software restriction policy based on the hash.
Hash-based rules have their strengths and weaknesses. The primary advantage to using a hash-based algorithm is that a file retains its hash regardless of its location. Therefore, even if someone renames or moves a file, the file will still retain its original hash. The downside to using hash-based rules is that if a program is modified at all, the hash will change and the rule will no longer apply.
Normally, an executable file will never be modified, and therefore the hash will never change, but there are exceptions to every rule. For example, if you install a service pack for an application, the service pack will update the executable and thus change its hash. Another possibility (however unlikely) is that if everyone has access to the folder containing an executable file, but only certain people have rights to run the file, then it’s possible for a user to use a hex editor to make a minor change to the file. This would change the file’s hash and, under the right circumstances, grant the user the ability to run the program because the hash rule would no longer apply.
Before I show you how to create a hash rule, there’s one more thing that you need to know. In order to create a hash rule, you must use the hash as determined by the Software Restriction Policy software. You can’t just import a hash that was calculated by another software component, even if the hash matches and uses the same hash algorithm.
To create a hash rule, right-click the Additional Rules container in the Group Policy Editor and select the New Hash Rule command from the resulting shortcut menu. This will reveal the New Hash Rule dialog box, as shown in Figure B.
|A hash rule uniquely identifies a file by using a number that’s based on a mathematical equation.|
The first thing that you must do to create a new hash rule is to enter the filename that you want to create the hash for. The best way to do this is to use the browse option to locate and select the file. Once you’ve selected the file, the file hash and file information fields are filled in automatically. Then you simply enter a description to help you to figure out what the rule does and to select the appropriate security level.
One of the reasons why there are so many different types of rules is that not all types of rules will work with all types of applications. For example, a certificate rule won’t work with applications that use the EXE or DLL file extensions. Instead, certificate rules can only be applied to scripts and to Windows installer packages.
For example, you’d use certificate rules in situations in which you wanted to create software restriction policies that automatically trust software installation programs located within the domain. This will prevent the user from ever being told who signed the code or being asked if they want to accept the signature. Likewise, you can create certificate rules that deny specific certificates. If, however, you wanted to deny privileges to all software that doesn’t contain a specific digital signature, you’d have to create a certificate rule that permitted the acceptable certificate and then create a path rule that denied everything else (remember rule precedence). Unfortunately, there’s no setting to disallow unsigned code. Any certificate rules that you create must be based on specific certificates. To create a certificate rule, first look at the Security Levels container. You’ll notice that there are already Disallowed and Unrestricted policies, as shown in Figure C.
|There are two preexisting security levels to choose from.|
Pay attention to the wording in the description fields next to the security levels. The Disallowed software policy prevents software from running, regardless of any other access rights that the user may have. The Unrestricted policy allows software to run, but only if the user has the necessary permissions. Simply setting an unrestricted policy won’t let a user run software that they don’t have rights to. Another thing that you might notice about the Security Levels container is that if you right-click the container, there are no options to create any additional security levels. Software is either allowed or it isn’t.
To continue with creating a certificate rule, right-click the Additional Rules container and select New Certificate Rule from the resulting shortcut menu. This will reveal the New Certificate Rule dialog box, as shown in Figure D. This dialog box allows you to use a rule to override the default security level that’s associated with a signed script or Windows installer package.
|The New Certificate Rule dialog box allows you to use a rule to override the default security level that’s associated with a signed script or Windows installer package.|
To continue creating the new certificate rule, click the Browse button. This will open the Browse window, which you can then use to locate the certificate that you wish to apply the new rule to. Once you’ve located the certificate, you can set the security level associated with it to either Unrestricted or Disallowed. After you set he security level, it’s often helpful to fill in a description of what the rule does. After all, most certificates look alike, and you may not be able to identify what a certificate (or the rule) does just by glancing at it unless you enter a description.
Path rules either grant or deny access to a program, based on the program’s path. For example, you could either allow or disallow access to C:\Program Files\SomeApplication via a path rule. The biggest thing to remember about path rules is that they are not dynamic in nature. Therefore, if you move an application, the path rule will no longer apply.
In the real world, path rules are most commonly used to allow applications in specific locations when a blanket default policy disallows everything. Whenever you create path rules, one thing to keep in mind is that path rules support the use of variables, such as %systemroot%, %windir%, %appdata%, %programfiles%, and %temp%.
To create a path rule, right-click the Additional Rules container and select the New Path Rule command from the resulting shortcut menu. This will reveal the New Path Rule dialog box shown in Figure E.
|The New Path Rule dialog box asks you for the desired path and security level.|
Filling in the New Path Rule dialog box is pretty simple. Begin the process by entering the desired path into the Path text box. If you like, you can even use the Browse button to browse for and select a path. This prevents you from making a typo. Once you’ve selected the desired path, set the security level to either Unrestricted or Disallowed. As with the other rules, you’ve also got the option of entering a description to go with the new rule. When you’re done creating the rule, just click OK.
Internet zone rules
If you’ve ever worked with the security settings in Internet Explorer, then you’re probably already familiar with the concept of Internet Explorer zones. The Internet zone rules take this concept a step further by either allowing or disallowing users to run software, based on the Internet zone that the software came from. The biggest thing that you have to remember about zone rules is that they apply only to Windows installer files.
To create an Internet zone rule, right-click the Additional Rules container and select the New Internet Zone Rule command from the resulting context menu. When you do, you’ll see the New Internet Zone Rule dialog box shown in Figure F.
|The New Internet Zone Rule dialog box lets you allow or disallow Windows installer packages based on the Internet zone that they came from.|
Setting up an Internet zone rule is simple. All you have to do is to select the desired zone level and the desired security level and click OK. The basic idea behind creating these rules is that you should create rules that allow Windows installer files to run only if those files came from Internet zones containing Web sites that you trust not to damage your system or data.
Now that you know how to implement software restriction policies, it’s time to take a look at some best practices for implementing those policies. The best advice that I can give you is to always test a new policy thoroughly on a single machine before rolling it out to other machines. If time allows, I recommend testing the new policy for at least a week or two before the rollout. While it will be obvious whether or not the policy is working, policies can have unexpected side effects if not implemented carefully, and it’s important to catch those side effects before you implement the new policy on a large scale.
You shouldn’t get too restrictive with your policies. You might be surprised at how many applications the system needs just to be able to function correctly. For example, many applications (especially Microsoft Office) call other applications or code segments in order to perform certain functions. Likewise, policies that are too restrictive can prevent login scripts from running, or prevent certain programs from running on Startup. Therefore, be sure to check the Start Up folder and the HKEY_Current_User\Software\Microsoft\Windows\CurrentVersion\Run registry key to see what applications are loaded on startup.
Finally, if you’re serious about disallowing a lot of applications, then be sure to create a path rule that disallows programs from running in %windir%\system32\dllcache. This is a cache folder that often contains cached copies of applications. Applications can run from within this folder even if you have disallowed them elsewhere, unless you disallow the folder.