Supporting Desktop Applications : Troubleshoot Software Restrictions

Reviewing Software Restriction Policies

Before you get into using Software Restriction policies, take some to time to review the four available policies. You need to be clear about their capabilities and what they do so that later when you discuss their use either alone or in conjunction with another type of Software Restriction policy, you have a better handle on what results you can expect. Software Restriction policies are put in place to protect against malicious code as well as unknown code. This section starts by listing the four software rules that identify software and then identifies the three security levels in which they are enforced.

The four rules that identify software are

• Certificate— A certificate from a software publisher that is digitally signed.

• Hash— A cryptographic fingerprint that uniquely identifies a file.

• Path— Use of local path or universal naming convention (UNC) path to the place where a file is stored. A path rule can be a file path, Registry path, or path that employs wildcards.

• Network Zone— Defined network locations such as Internet, Local Intranet, Restricted Sites, Trusted Sites, and Local Computer.

Security levels are employed to dictate a default rule for all software, along with exceptions for software that should not run, may always be run, or run using a normal user security level. These three security levels are

• Unrestricted— This is the default security level for all Software Restriction policies. This rule should be used if, as administrator, you are aware of all software that should be run. You can set the default policy to Disallowed and create an unrestricted rule for all known software that can be run.

• Disallowed— This rule should be used if, as administrator, you are aware of all software that should not be run. You can set the default policy to Unrestricted and create a disallowed rule for all known software that should not be run.

• Basic User— As administrator, you should employ this rule where software is known to run with only normal user security. For example, you can set the default policy to Disallowed and configure a policy for all other software that can be run under normal user security.

Employing Software Restriction Policies

Using the rules individually or in combination with other rules is where the complexity begins. Rules need to be applied based on a processing priority along with the knowledge that any software this is going to be allowed to run will take into consideration any user security set at the folder and file level. Rules that identify software are evaluated such that the more specific rule takes precedence. So the processing of rules in order of precedence is

Following are some implementation examples. For instance, if the default rule Unrestricted is in use, but you know that most scripts should never be run except for a few in a select folder, you could employ the following rules to meet these goals.

Or you could possibly use

If a company wants to restrict users from running multimedia applications such as Real Player or Windows Media Center, it can create an exception to the default rule Unrestricted. An exception rule can use either a path rule specifying the exact path or a hash rule specifying the exact executable that runs the multimedia applications. The exception rules are seen as more specific and thus override the default Software Restriction of Unrestricted.

Now use the initial scenario as a guideline. What if the company wants to ensure that script files run from a designated \scripts folder are authorized to be run? The company can employ multiple Software Restriction rules to ensure this goal:

Monitoring Software Restriction Policies

With so many variables possible with Software Restriction policies, you need a tool or two to help troubleshoot problems arising when multiple Software Restriction policies are employed in an environment. Using the Resultant Set of Policy (RSoP) standalone snap-in or the newer Group Policy Management Console (GPMC) that has integrated much of the RSoP snap-in functionality, you can ascertain the effective Group Policy settings on users and computers. Figure 1 shows one of the two ways RSoP (Group Policy Results in the GPMC) is employed within the Group Policy Management Console.

Figure 1. Using RSoP within the GPMC.

The Group Policy Results summary report shown in Figure 1 is based on actual Group Policy applied to the user named Paul using the computer VISTA-PCMOBILE.

The Group Policy Modeling node displays RSoP data based on “what if” scenarios. In other words, what if a user from a specific container (Organizational Unit or domain) is using a computer from another container with the respective policies applied? The report generated is to simulate the effects of given policies applied to specific containers of users and computers.

Using these two powerful reports, you can detect problems or conflicts with Group Policy settings. This includes issues arising from conflicting Software Restriction polices. Another possible utility that allows the viewing of RSoP data is the gpresult command-line utility. This utility allows you to view all Group Policy objects and their effects.

There are some common problems to look out for when implementing Software Restriction policies. The following list should not be considered complete but can be used as a guideline for additional items to be aware of when creating Software Restriction rules:

• Know the location of all login scripts to ensure their use.

• Windows Vista system file protection makes duplicate copies of most system applications and stores them in the folder %WINDIR%\system32\dllcache. Create a rule to disallow execution of applications from this directory.

• Note startup locations for applications on a computer. For example, the Startup folder for each user in her profile is one of many different areas to look out for applications that run at startup. Other locations consist of the Run key in the Registry for the current user as well as the All Users, Scripts, and Startup folder for the All Users profile.

• Do not disallow antivirus, antispyware, or antimalware applications from running, including those that look for real-time exploits.

• Watch out for malicious .vbs scripts. Over the years, this has been the most prolific means of introducing malware.

• Allow only authorized application installations. Disallow any other unauthorized applications from installing on user and server computers.

• If different users are using a computer, ensure that Software Restriction policies are applied on a per-user basis if there are differences in what each user is allowed to run.