Software Restriction Policy

Windows XP and Windows 2003 servers have a CSE (Client Side Extension) that Windows 2000 doesn't have: Software Restriction Policies. Software Restriction Policies enable you, the administrator, to precisely dictate what software will and will not run on your Windows XP desktops.

Many viruses show up in your users' inboxes as either executables or .vbs scripting files. Just one launch within your confines, and you're cleaning up for a week. Additionally, users will bring in unknown software from home or download junk off the Internet, and then, when the computer blows up, they turn around and blame you. What an injustice!

To that end, Microsoft developed Software Restriction Policies, which can put the kibosh on software that shouldn't be there in the first place. You can restrict software for specific users or for all users on a specific machine. You'll find Software Restriction Policies in Computer Configuration ˜ Windows Settings ˜ Security Settings ˜ Software Restriction Policies. Just right-click over the Software Restriction Policies node, and select "New Software Restriction Policies" as shown in 6.14 to get started.

Software Restriction Policies is also available as a node under User Configuration ˜ Windows Settings ˜ Security Settings ˜ Software Restriction Policies , which can also be seen in Figure 6.14.

Figure 6.14: Software Restriction Policies are available in both the Computer and User nodes.

Like other policies that affect users or computers, you'll need an OU containing the user or computer accounts you want to restrict, and you'll need a GPO linked to that OU. Or you can set a GPO linked to the domain level, which affects all Windows XP and Windows 2003 machines (or, alternatively, users). Typically, you'll use the Computer side branch of Software Restriction Policies. That way, all users on a specific machine are restricted from using specific "known bad" applications.

Tip 

Software Restriction Policies are also valid when set upon a local computer within a local policy (via GPEdit.msc) . This can be particularly useful for a Windows 2003 acting as a Terminal Server. Software Restriction Policies are meant to replace the APPSec.exe tool.

GPOs containing Software Restriction Policies might be common in environments that include Windows XP, Windows 2003, and Windows 2000 machines. However, Windows 2000 machines that are affected by GPOs containing Software Restriction Policies will simply ignore the settings and restrictions contained within.

Software Restriction Policies' "Philosophies"

Using Software Restriction Policies with your Windows XP users involves three primary philosophies. You can choose your philosophy by selecting the "Security Levels" branch of Software Restriction Policies as shown in Figure 6.15.

Figure 6.15: The Security Levels branch of Software Restriction Policies sets your default level of protection.

Philosophy #1 Allow everything to run except specifically named items. I nickname this one "Nearly open door." The "Unrestricted" option is selected. Windows XP allows all programs to run, like normal. However, if the administrator names certain applications, such as a virus or a game, it will be prevented from running.

Philosophy #2 Don't allow programs of a certain type to run. Allow only specifically named items of that type to pass. I nickname this one "Doggie Door." The "Unrestricted" option is selected. You can choose to squelch all files of a certain type, say, all .vbs files. However, you can instruct Windows XP to allow .vbs files that are digitally signed from your IT department to run.

Philosophy #3 Nothing is allowed to run but the operating system and explicitly named items. This is the "Full Lockdown" approach. The "Disallowed" option is selected. This is the most heavy-handed approach, but the safest. Only operating system components will run, unless you specifically open up ways for programs to be run. Be careful when using this method; it can get you into a lot of trouble quickly.

Software Restriction Policies' Rules

Once you've chosen your philosophy, you can choose how wide the door is for other stuff. There are four rules to either allow or deny specific software:

• Hash

• Path

• Certificate

• Internet Explorer zone

To create a new rule, select the "Additional Rules" folder, and right-click in the right pane to see your choices, as shown in Figure 6.16.

Figure 6.16: The Security Levels branch of Software Restriction Policies sets your default level of protection.

Note 

By default four Path rules are set that enable access to critical portions of the Registry. These are enabled so that the operating system can write to the Registry even if the "Disallowed" option is set in the "Security Levels" branch.

Hash Rule In computer science terms, a "hash value" is a numeric representation, or fingerprint , that can uniquely identify a file should it be renamed . It's sort of like a "checksum" value. For instance, if I rename Doom.exe to Gloom.exe , the actual bits, the 1s and Os, contained within the .exe file are the same. Therefore, the hash value is the same. However, if any changes are made to the file (even if one bit is changed), the hash value is different. Hash rules are quite useful in containing any application that's an .exe or a .dll .

Sure, it's true that a user could use a hex editor (such as FRHED from www.kibria.de/frhed.html ) and change just one bit in an .exe or .dll file to get a new hash value, but it's bloody unlikely . And that's reasonably good protection for most of us. A little review/tutorial of FHRED can be found here: www.geocities.com/thestarman3/tool/frhed/FRHED.htm .

Path Rule You can specify to open (or restrict) certain applications based on where they reside on the hard drive. You can set up a Path rule to specify a specific folder or full path to a program. Most environment variables are valid such as %HOMEDRIVE%, %HOMEPATH%, %USERPROFILE%, %WINDIR%, %APPDATA%, %PROGRAMFILES%,and %TEMP%. Additionally, Path rules can stomp out the running of any file type you desire , say, Visual Basic files. For example, if you set up a Path rule to disallow files named *.vb* , all Visual Basic file variants will be unable to execute.

Certificate Rule Certificate rules use digitally signed certificates. You can use certificate rules to sign your own applications or scripts and then use a certificate rule to specify your IT department as a "Trusted Publisher." Users, admins, or Enterprise Admins can be specified as trusted publishers. Be sure to read the sidebar entitled "Software Restriction Policies and Digital Signatures" before rolling out Certificate Rules.

Internet Zone Rule Users will download crap off the Internet. This is a fact of life. However, you can specify which Internet Explorer zones are allowed for download. You can specify Internet, Intranet, Restricted Sites, Trusted Sites, and My Computer. The bad news about Zone rules, however, is that they simply aren't all that useful. They prevent downloads of applications with the MSI format, but nothing else. So, in my opinion, they're not quite ready for primetime use. (Note that we talk more about MSI files in Chapter 10.)

Setting Up a Software Restriction Policy with a Rule

As stated, you can craft your Software Restriction Policies in myriad ways. Space doesn't permit explaining all of them, so I'll just give you one example. We'll test our Software Restriction Policies by locking down a nefarious application that has caused countless distress to innumerable, hapless people: Solitaire for Windows XP!

To restrict Solitaire from your environment, follow these steps:

1. Create a new hash rule as seen in Figure 6.16 earlier in this chapter.

2. Click Browse, and locate Sol.exe .

Tip 

You might have to type \\XPPR01\c$\windows\system32\sol.exe to point to a copy of Solitaire on one of your Windows XP machines if you're logged on at a domain controller (because Solitaire isn't present on Windows 2003 servers). If you have Windows XP/Service Pack 2 loaded on your client system, you can't do this until the SP2 firewall is turned off.

The "File hash" entry is filled in with the file hash value of Sol.exe from the machine, as shown in Figure 6.17.

Figure 6.17: Once you specify the file, the hash value is filled in.

Testing Your Software Restriction Policies on Windows XP

In the previous example, you could create a Software Restriction Policy that affects users or computers. If your policy is for users, for this very first test, log off. If your policy is for computers, reboot the machine. Follow these steps to immediately demonstrate the desired behavior of Software Restriction Policies.

1. Log on the machine that should get the Software Restriction Policies.

2. Choose Start ˜ Run to open the Run dialog box.

3. In the Open box, type Sol.exe . You'll see the message shown in Figure 6.18.

Figure 6.18: On Windows XP machines, Solitaire is prevented from running.

If you were to open a command prompt and then type Sol.exe , you would also be restricted. You'll see the message "The system cannot execute the specified program." This is what you expect. Software Restriction Policies are enforced. However, Software Restriction Policies has some strange behavior when the policy is removed (or reenabled), and this behavior is vitally important for you to understand in order to make the most out of Software Restriction Policies.

Software Restriction Policies and Digital Signatures

Note that there is a security policy setting named System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies located in Computer Configuration ˜ Windows Settings ˜ Security Settings ˜ Local Policies ˜ Security Options.

You'll need to enable this policy setting if you create a Hash rule or Certificate rule on a digitally signed .EXE. You can tell if a file is digitally signed by checking out its properties and looking for a Digital Signatures tab, as seen here in the file's properties. Winword.exe has a Digital Signatures tab, while Calc.exe has none.

In the earlier example, when we set a Hash rule upon Calc, enabling this policy setting was unnecessary because calc.exe isn't digitally signed. However, if you were to restrict a digitally signed .EXE, such as WINWORD.EXE, this policy setting would be necessary for the Hash rule to be embraced by your client systems.

As stated, this policy setting is only necessary for digitally signed .EXEs. However, if you only deal with digitally signed VBS or MSI files, you don't have to worry about this setting at all.

 

Understanding When Software Restriction Policies Apply

As you just saw, Software Restriction Policies appear to apply at the initial policy processing time, that is, when the user logs on to the machine. However, Group Policy's "Initial policy processing" isn't the mechanism that enforces the Software Restriction Policies. This is a little confusing, so stay with me.

When you log on to a machine, you're running a shell program that launches other programs. This is sometimes called a "launching process." That shell program (or launching process) is familiar Explorer.exe . Whenever Exp1orer.exe (or other launching processes) launch restricted software, they check a portion of the Registry for any restrictions. How does this help determine when Software Restriction Policies apply?

Tip 

Software Restriction Policies are housed in KEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers .

When Windows XP (pre-SP2) Applies Software Restriction Policies

Let's imagine that we haven't deployed any Software Restriction Policies to our computers or users and walk through a basic scenario:

Sally the nurse is already logged on to XPPRO2 (her workstation) in the Nurses OU. She likes to play Solitairea lot. We want to prevent the computers in the Nurses OU from running Solitaire ( Sol.exe ). We create a new GPO called "Computer Side Software Restriction" and link it to the Nurses OU. We drill down into Computer Configuration ˜ Windows Settings ˜ Security Settings ˜ Software Restriction Policies . Our new Software Restriction Policy contains a Hash rule to restrict Solitaire. Group Policy applies in the background (maximally 120 minutes later), or you ask Sally to run GPUpdate /FORCE . This guarantees that the GPO containing the Software Restriction Policy is received.

Now, you want to see how Sally (who is already logged on) will embrace the Software Restriction Policy.

If Sally is running Sol.exe , it will continue to run until she closes it. You can understand how this makes sense. However, after she closes it, things get strange.

• If Sally then choose Start ˜ Run to open the Run dialog box, then enters CMD in the Open box (to spawn a new shell), types Sol.exe , and then presses Enter, Solitaire will be restricted.

• If Sally chooses Start ˜ All Programs ˜ Games ˜ Solitaire (or chooses Start ˜ Run to open the Run dialog box, types Sol.exe in the Open box, and then presses Enter, Solitaire will run!

You can see this interaction in Figure 6.19. Again, this is only for Windows XP (pre-SP2).

Figure 6.19: On Windows XP (pre-SP2), a logoff and logon will be required for all "Launching Programs" to get the signal to restrict software.

Looking at Figure 6.19, we see in number 1 that the topmost command prompt was opened first. In this command prompt, GPUpdate /FORCE was run to make sure the computer received the GPO containing the Software Restriction Policy. In number 2, Sally then opened a new command prompt and tried to run Sol.exe . It is restricted. You can see the command prompt respond with "The system cannot execute the specified program." Yet, when Sally then ran Sol.exe via Explorer (that is, from the Start menu), in number 3, Solitaire ran, as seen in number 4.

Why does this happen?

Because the "Launching programs" (either CMD or Explorer) control which software is restricted. And it's the launching program that needs to get the "signal" from the Software Restriction Policiesnot the actual application! And the launching program only checks Software Restriction Policies when it's first initialized . For Explorer, that's when the user logs on.

So, when Sally logs off and logs back onshe again uses the Start menu and locates and starts Solitaire (or uses the Run dialog box)Solitaire is restricted. This is because Explorer (the launching program) has been refreshed and checks the Software Restriction Policies entries in the Registry.

When Windows XP/SP2 or Windows 2003 (Any SP) Applies Software Restriction Policies

If you place Software Restriction Policies on Windows XP/SP2 or Windows 2003 (any SP), the Software Restriction Policies apply a bit more rationally. That is, as soon as the Software Restriction Policies are downloaded via Active Directory Group Policy, no new instances of that application are possible.

It doesn't matter if the launching program (i.e., Explorer) has already been started; it doesn't need a refresh. It just restricts the software as specified in the Software Restriction Policies as soon as the Group Policy containing the Software Restriction Policies is applied. This is good. Very good.

And Windows XP + SP2 now acts just like Windows 2003. As soon as a GPO that has Software Restriction Policies meant for either the user or computer is embraced by the client machine, the rule takes effect immediately. Thank goodness! Note, however, that programs already running don't magically stop running. This will only prevent future instances of the specified application from running.

However, one Windows 2003 Software Restriction Policy anomaly should be noted. Specifically, if you log on locally to a standalone or member server and create a Software Restriction Policy, the Software Restriction Policy acts like Windows XP. That is, the "launching program" must be reset in order for the Software Restriction Policy to take effect. Again, this is only when local GPOs are set upon Windows 2003 standalone or member machines.

Troubleshooting Software Restriction Policies

You can troubleshoot Software Restriction Policies in two primary ways:

• Inspect the Registry to see if the Software Restriction Policies are embraced.

• Enable advanced logging.

Inspecting the Software Restriction Policies Location in the Registry

If Software Restriction Policies aren't being applied, and you logged off and back on, log on again as the administrator at the target machine and check KEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers . Inside, you'll see numbered branches containing the rules. In Figure 6.20, you can see Sol.exe being restricted by a hash rule.

Figure 6.20: The Registry lays out what will be restricted.

Do note that operating system files change with service packs sometimes, even innocuous things like Sol.exe! If, after a service pack, your client isn't restricting applications as you expect, make sure the version number of the restricted application matches the version actually located on the client. More specifically, make sure the hash values match.

Software Restriction Policies Advanced Logging

You can troubleshoot Software Restriction Policies via a log file. To do so, follow these steps:

1. In the Registry, traverse to KEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers .

2. Create a new string value named LogFileName .

3. In the Data field of the new Registry key, enter the full path and name of a log file, for example, c:\srplog.txt .

Now, whenever an application runs, a line is written to the log file explaining why it can or cannot run. Here are two lines from that log file: the first when I run Notepad (which is free to run), and the second when I run the Sol.exe (which is restricted).

 cmd.exe (PID = 1576) identified C:\WINDOWS\system32\notepad.exe as Unrestricted      using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca} cmd.exe (PID = 1576) identified C:\WINDOWS\system32\sol.exe as Disallowed using      hash rule, Guid = {e669efa3-96d8-4c16-b506-2fec88fbee33} 

Tip 

You'll find a great article on Software Restriction Policies in TechNet. Just search on "Using Software Restriction Policies to Protect Against Unauthorized Software."

Oops, I Locked Myself Out of My Machine with Software Restriction Policies

If you make a Software Restriction Policy too tight, you can lock yourself right out of the system! Don't panic. If the policy is a GPO in Active Directory, remove the policy setting or disable the GPO. After Group Policy processes on the client, log on again as the user, and you should be cleared up.

However, if you make a Software Restriction Policy using the local policy editor ( GPEdit.msc ) and you lock yourself out, you have a slightly longer road to recovery. Follow these steps:

1. Reboot the machine, and press F8 upon startup to open the Advanced Options Menu at boot time.

2. Select SAFE MODE and allow the computer to continue to finish booting.

3. Log on as the machine's local administrator.

4. Dive in to HKLM\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers . Delete everything below the "Codeldentifiers" key.

5. Reboot the machine.

You should be out of the woods now.