Using Software Restriction Policies to Protect Against Unauthorized SoftwarePublished: October 2, 2006 Abstract Software restriction policy is a feature in Microsoft Windows XP, Microsoft Windows Server 2003, and Microsoft Windows Vista. This important feature provides administrators with a policy-driven mechanism for identifying software programs running on machines in a domain, and controls the ability of those programs to execute. Software Restriction Policies can improve system integrity and manageability, which ultimately lowers the cost of owning a personal computer. On This Page Introduction
Software Restriction Policies—An Overview
Software Restriction Policy Architecture
Software Restriction Policy Options
Software Restriction Policy Design
Step-by-Step Guide for Designing a Software Restriction Policy
Step-by-Step Guide for Creating Additional Rules
Commonly Overlooked Rules
Scenarios
Deployment Considerations
Troubleshooting Software Restriction Policies
Appendix
Summary
Related Links
IntroductionSoftware restriction policies are part of Microsoft’s security and management strategy to assist enterprises in increasing the reliability, integrity, and manageability of their machines. Software restriction policies are one of many important management features in Windows Vista and earlier operating systems (Windows XP and Windows Server 2003). In Windows Vista and Windows Longhorn Server, software restriction policies include some new features to meet current security challenges. This article provides an in-depth look at the new Software Restriction Policy features. | • | The addition of another default security level for more granularity (Basic User). | | • | Support for SHA256 algorithm hash rules. | | • | Enabling certificate rules through the Enforcement Property dialog box. | | • | Trusted publisher property dialog UI changes. |
This article also provides an in-depth look at how software restriction policies can be used to: | • | Fight viruses. | | • | Regulate which Microsoft ActiveX controls can be downloaded. | | • | Run only digitally signed scripts. | | • | Enforce that only approved software is installed on system computers. | | • | Lock down a machine. |
Expanded Management CapabilitiesMicrosoft Windows 2000 brought significant management capabilities to the Microsoft Windows platform. In Windows 2000, you could manage the software for your machines in the following ways | • | Application settings allowed you to customize an application once through Group Policy, and then distribute that customization to all domain users who required it. | | • | The Software Installation snap-in provided a means to centrally manage software distribution in your organization. When the user selected an application from the Start menu for the first time, the application was set up automatically, and then opened. You could also publish applications to groups of users, making the application available for users to install. | | • | Security settings defined a security configuration within a Group Policy Object (GPO). Security configuration consisted of settings for: account policies, local policies, event log, registry, file system, public key policies, and other policies. |
Windows XP and Windows Server 2003 expand the management capabilities of Windows 2000 by adding the following features | • | Better diagnostic and planning information through the Resultant Set of Policies (RSOP). For more information, see the Windows Server 2003 Group Policy article. Windows 2003 Group Policy | | • | Ability to use Windows Management Instrumentation (WMI) filtering. In Windows 2000, you could apply policies based on organizational information in Microsoft Active Directory. In Windows XP, you can use WMI information to apply group policies, for example, to machines with a certain build or service pack level of Windows. |
Software restriction policies integrate with the operating system and common scripting runtimes to control the running of software at execution. In Windows 2000 you could hide access to applications by removing them from the Start menu or hiding the Run command. New software restriction policies go beyond this by simply removing the common access points for software. Top of page
Software Restriction Policies—An OverviewThis section discusses the behavior of hostile code and problems associated with unknown code. Hostile Code Can Infiltrate EasierWith the increased use of networks and the Internet in daily business computing, the potential for encountering hostile code is higher than ever before. People collaborate in more sophisticated ways by using e-mail, instant messaging, and peer-to-peer applications. As these collaboration opportunities increase, so does the risk of viruses, worms, and other hostile code invading your systems. It is important to note that e-mail and instant messaging can transport unsolicited hostile code. Hostile code can take many forms—it can range from native Windows executables (.exe), to macros in word processing documents (.doc), to scripts (.vbs). Viruses and worms often use social engineering to trick users into activating them. With the sheer number and variety of forms that code can take, it can be difficult for users to know what is safe to run. When activated, hostile code can damage content on a hard disk, flood a network with a denial-of-service attack, send confidential information to the Internet, or compromise the security of a machine. The Problem with Unknown CodeHostile code is not the only threat—many non-malicious software applications also cause problems. Any software not known and supported by an organization can conflict with other applications or change crucial configuration information. Software restriction policies were designed to help organizations control not just hostile code, but any unknown code—malicious or otherwise. Responding to Unknown CodeSoftware restriction policies help a business respond to unknown code by: | • | Providing a way to define a list of what is trusted code versus what is not. | | • | Providing a flexible, policy-based approach for regulating scripts, executables, and ActiveX controls. | | • | Enforcing the policy automatically. |
Top of page
Software Restriction Policy ArchitectureFigure 1 shows the three components of a software restriction policy 1. | An administrator creates the policy by using the Group Policy Microsoft Management Console (MMC) snap-in for a particular Active Directory container site, domain, or organizational unit (OU). | 2. | The policy is downloaded and applied to a machine. User policies apply the next time a user logs on. Machine policies apply when a machine starts. | 3. | When a user starts a program or script, the operating system or scripting host checks the policy and enforces it. |
.jpg)
Figure 1: Three Components of a Software Restriction Policy Default Rule or Default Security LevelA software restriction policy is created using the MMC Group Policy snap-in. A policy consists of a default rule about whether programs are allowed to run, and exceptions to that rule. The default rule can be set to Unrestricted, Disallowed, or Basic User—run, do not run, or run as a normal user. Setting the default rule to Unrestricted allows an administrator to define exceptions, for example, the set of programs that are not allowed to run. A more secure approach is to set the default rule to Disallowed, and specify only the programs that are known and trusted to run. An intermediate secure approach is to set the default rule to Basic User. This means that when no exception rule match is found, the application will be run as a normal user. Note Normal user has the following security identifiers (SIDs) disabled: Admins, cert admins, schema admins, enterprise admins, policy admins, and all privileges. Warning Some applications that require admin privileges might not run as a normal user. Security LevelThis is the security level for exception (additional) rules defined with reference to the default rule. Software restriction policies can be used in the following three ways. | • | Unrestricted. If an administrator knows all the software that should run, a software restriction policy can be applied to control execution for only this list of trusted applications. For example, a software restriction policy can be created with a disallow default rule and exception (additional) rules with Unrestricted security level to all the software that should be run. | | • | Disallowed. If an administrator knows all the software that should not run, administrators disallow undesired applications or file types, as needed. For example, a software restriction policy can be created with an unrestricted default rule and exception (additional) rules with Disallowed security level to all the software that should not be run. | | • | Basic User. If an administrator knows all the software that should always be run as a normal user, a software restriction policy can be applied to control execution as a normal user to only this list of trusted applications. For example, a software restriction policy can be created with an unrestricted default rule and exception (additional) rules with Basic User security level to all the software that should always be run as a normal user. |
Four Rules Identify Software (Additional Rules)Four types of additional rules can be defined in a software restriction policy. The purpose of an additional rule is to identify one or more software applications, and specify whether they are allowed to run. Creating additional rules largely consists of identifying software that is an exception to the default rule. Each rule can include descriptive text to help communicate why the additional rule was created. A software restriction policy supports the following four ways to identify software | • | HashHash. A cryptographic fingerprint of the file. | | • | Certificate. A software publisher certificate used to digitally sign a file. | | • | Path. The local or universal naming convention (UNC) path to where the file is stored. | | • | Network Zone. The network zone. |
Hash Rules A hash rule is a cryptographic fingerprint that uniquely identifies a file regardless of where it is accessed or what it is named. An administrator may not want users to run a particular version of a program. This may be the case if the program has security or privacy bugs, or compromises system stability. With a hash rule, software can be renamed or moved into another location on a disk, but it will still match the hash rule because the rule is based on a cryptographic calculation involving file contents. In Windows Vista a new hash rule will contain two hashes (MD5 or SHA-1) and SHA-256. In earlier versions of Windows (Windows XP and Windows Server 2003), the default hash was MD5. The software restriction policy hash was upgraded to support a new algorithm (SHA-256) as part of a Windows-wide upgrade in cryptographic algorithms. Computers running Windows Vista will always try to read the SHA256 hash first. Why were two hashes created (MD5 or SHA-1 hash along with SHA-256 hash)? Software restriction policy server and clients might run on different operating systems. It is important to ensure that an Software restriction policy Group Policy created on a Windows Longhorn Server could be correctly applied on a down-level client. Conversely, the Windows XP or Windows Server 2003 software restriction policy could be applied on a Windows Vista client. Changes to Safer Application Programming Interfaces (APIs) To facilitate this hash algorithm upgrade, the safer APIs will contain two new data structures. SAFER_CODE_PROPERIES SAFER_HASH_IDENTIFICATION2 For more information about safer API usage, see winsafer.h in platform SDK Certificate Rules A certificate rule specifies a code-signing, software publisher certificate. For example, a company can require that all scripts and ActiveX controls be signed with a particular set of publisher certificates. Certificates used in a certificate rule can be issued from a commercial certificate authority (CA) such as VeriSign, a Windows Longhorn Server/Windows Server 2003 Public Key Infrastructure (PKI), or a self-signed certificate. A certificate rule is a strong way to identify software because it uses signed hashes contained in the signature of the signed file to match files, regardless of name or location. If you want to make exceptions to a certificate rule, you can use a hash rule to identify the exceptions. Note Certificate rules are not enabled unless they are enabled in the Enforcement Property dialog box. The Basic User security level is not supported for certificate rules. Path Rules A path rule can specify a folder or fully qualified path to a program. When a path rule specifies a folder, it matches any program contained in that folder and any programs contained in subfolders. Both local and UNC paths are supported. Using Environment Variables in Path Rules. A path rule can use environment variables. Since path rules are evaluated in the client environment, the ability to use environment variables (for example, %WINDIR%) allows a rule to adapt to a particular user's environment. Important Environment variables are not protected by access control lists (ACLs). If users can start a command prompt, they can redefine an environment variable to a path of their choosing. Using Wildcards in Path Rules. A path rule can incorporate the question mark (?) and asterisk (*) wildcards, allowing rules such as "*.vbs" to match all Microsoft Visual Basic Script files.Example | • | "\\DC-??\login$" matches \\DC-01\login$, \\DC-02\login$ | | • | "*\Windows" matches C:\Windows, D:\Windows, E:\Windows | | • | "c:\win*" matches c:\winnt, c:\windows, c:\windir |
Registry Path Rules. Many applications store paths to their installation folders or application directories in the Windows registry. You can create a path rule that looks up these registry keys. For example, some applications can be installed anywhere on the file system. These locations may not be easily identifiable by using specific folder paths, such as C:\Program Files\Microsoft Platform SDK, or environment variables, such as %ProgramFiles%\Microsoft Platform SDK. If the program stores its application directories in the registry, you can create a path rule that will use the value stored in the registry, such as %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PlatformSDK\Directories\Install Dir%. This type of path rule is called a registry path rule. The registry path is formatted as follows: %[Registry Hive]\[Registry Key Name]\[Value Name]% Note Any registry path rule suffix should not contain a backslash (\) character immediately after the last percent (%) sign in the rule. | • | The registry path must be enclosed in percent signs (%). | | • | The registry value must be a REG_SZ or REG_EXPAND_SZ. You cannot use HKLM as an abbreviation for HKEY_LOCAL_MACHINE, or HKCU as an abbreviation for HKEY_CURRENT_USER. | | • | If the registry value contains environment variables, these will be expanded when the policy is evaluated. | | • | A registry path rule can also contain a suffix path such as %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Cache%OLK*. This registry path rule identifies the folder that Microsoft Outlook XP uses to store attachments before launching them. The attachment folder always starts with the letters "OLK" so the rule uses wildcard matching. As an example, this rule matches the C:\Documents and Settings\username\Local Settings\Temporary Internet Files\OLK4 path. |
Important When you set a path rule, you should check the ACL entries on the path. If users have write access to a path, they can modify its contents. For example, if you allow C:\Program Files, any power user on the machine can copy software to the Program Files folder. Path Rule Precedence. When there are multiple matching path rules, the most specific matching rule takes precedence. The following is a set of paths, from highest precedence (more specific match) to lowest precedence (more general match). | • | Drive:\Folder1\Folder2\FileName.Extension | | • | Drive:\Folder1\Folder2\*.Extension | | • | *.Extension | | • | Drive:\Folder1\Folder2\ | | • | Drive:\Folder1\ |
Network Zone Rules A rule can identify software from the network zone from which it is downloaded. These zones are: | • | Internet | | • | Local Intranet | | • | Restricted Sites | | • | Trusted Sites | | • | Local Computer |
Currently, this applies only to Microsoft Windows Installer (*.MSI) packages. It does not apply to software downloaded in Microsoft Internet Explorer. When to Use Each RuleNote Each rule has a globally unique identifier (GUID) associated with it. An example GUID is {f8c2c158-e1af-4695-bc93-07cbefbdc594}. Two identical rules will have two different GUIDs. GUIDs help you troubleshoot to determine the specific rule in the specific policy that is being used. For more information, see the Troubleshooting section | Table 1 When to Use Each Rule | | Task | Recommended Rule | | You want to allow or disallow a specific version of a program. | Hash rule Browse to file to create hash | | You want to identify a program that is always installed in the same place. | Path rule with environment variables %ProgramFiles%\Internet Explorer\iexplore.exe | | You want to identify a program that can be installed anywhere on client machines. | Registry path rule %HKEY_LOCAL_MACHINE\SOFTWARE\ ComputerAssociates\InoculateIT\6.0\Path\HOME% | | You want to identify a set of scripts on a central server. | Path rule \\SERVER_NAME\Share | | You want to identify a set of scripts on a set of servers: DC01, DC02, and DC03. | Path rule with wildcards \\DC??\Share | | You want to disallow all .vbs files, except those in a login script directory. | Path rule with wildcards *.VBS set to Disallowed \\LOGIN_SRV\Share\*.VBS set to Unrestricted | | You want to disallow a file installed by a virus that is always called flcss.exe. | Path rule flcss.exe, set to Disallowed | | You want to identify a set of scripts that can be run anywhere. | Certificate rule Certificate used to digitally sign the scripts | | You want to allow software to be installed from trusted Internet zone sites. | Zone rule Trusted Sites set to Unrestricted |
Rule PrecedenceRules are evaluated in a specific order. The rules that more specifically match a program take precedence over rules that more generally match a program. | • | Certificate rule | | • | Hash rule | | • | Path rule | | • | Internet zone rule | | • | Default rule |
Table 2 and the following examples illustrate how rules are processed when a program is started. | Table 2 Understanding Rule Precedence | | Default Security Level: Unrestricted | | | | Hash Rules | | | | Rule 1 | Hash of pagefileconfig.vbs | Disallowed | | Certificate Rules | | | | Rule 2 | IT Management Certificate | Unrestricted | | Path Rules | | | | Rule 3 | %WINDIR%\System32\*.VBS | Unrestricted | | Rule 4 | *.VBS | Disallowed | | Rule 5 | %WINDIR% | Unrestricted |
Program being started: C:\WINDOWS\SYSTEM32\EventQuery.vbs This program matches the following rules | • | Rule 3 because it is a .vbs file in the System32 folder. | | • | Rule 4 because it has a .vbs extension. | | • | Rule 5 because it is stored in a subfolder of the Windows directory. |
Rule 3 is the most specific match for this program. Because Rule 3 has a security level of Unrestricted, the program is allowed to run. Program being started: C:\WINDOWS\SYSTEM32\pagefileconfig.vbs This program matches the following rules | • | Rule 1 because the hash in the rule matches the hash of the file. | | • | Rule 3 because it is a .vbs file in the System32 folder. | | • | Rule 4 because it has a .vbs extension. | | • | Rule 5 because it is stored in a subfolder of the Windows directory. |
Rule 1 is the most specific match for this program. Because Rule 1 has a security level of Disallowed, the program is disallowed. Program being started: \\LOGIN_SRV\Scripts\CustomerScript1.vbs This program matches the following rules | • | Rule 2 because it is digitally signed by the certificate belonging to the customer's IT management group. | | • | Rule 4 because it has a .vbs extension. |
Rule 2 is the most specific match for this program. Because Rule 2 has a security level of Unrestricted, the program is allowed to run. Program being started: C:\Documents and Settings\user1\LOVE-LETTER-FOR-YOU.TXT.VBS This program matches Rule 4 because it has a .vbs extension. Rule 4 is the most specific match for this program. Because Rule 4 has a security level of Disallowed, the program is disallowed. Top of page
Software Restriction Policy OptionsThis section discusses the various options that influence the behavior of a software restriction policy. These options alter the scope of enforcement behavior or the Authenticode trust settings for digitally signed files. Enforcement OptionsThe two enforcement options are dynamic-link library (DLL) checking and Skip Administrators. DLL Checking A program, such as Internet Explorer, consists of an executable file, iexplore.exe, and many supporting DLLs. By default, software restriction policy rules are not enforced against DLLs. This is the recommended option for most customers for the following three reasons. | • | Disallowing the main executable file prevents the program from running, so there is no need to disallow all the constituent DLLs | | • | DLL checking results in performance degradation. If a user runs 10 programs during a logon session, the software restriction policy is evaluated 10 times. If DLL checking is turned on, the software restriction policy is evaluated for each DLL load within each program. If each program uses 20 DLLs, this results in 10 executable program checks plus 200 DLL checks, so the software restriction policy is evaluated 210 times. | | • | If the default security level is set to Disallowed, not only does the main executable file have to be identified to allow it to run, but all of its constituent DLLs must also be identified, which can be burdensome. |
DLL checking is provided as an option if you want the highest assurance possible when running programs in your environment. While viruses primarily target executables for infection, some target DLLs. To ensure that a program has not been infected by a virus, you can use a set of hash rules that identify the executable and all its required DLLs. To turn on DLL checking | • | In the Enforcement Properties dialog box, select the following option (as shown in Figure 2). Apply software restriction policies to the following > All software files |
.jpg)
Figure 2: Setting Enforcement Properties Skip AdministratorsAn administrator may want to disallow the running of programs for most users, but allow administrators to run all programs. For example, a customer may have a shared machine that multiple users connect to using Terminal Server. The administrator may want users to be able to run only specific applications on the machine, but allow members of the local administrators group to run any program. To do this, use the Skip Administrators option. If the software restriction policy is created in a GPO attached to an object in Active Directory, the preferred way to use this option is to deny the Apply Group Policy permission on the GPO to a group containing the administrators. This way less network traffic is consumed downloading GPO settings that do not apply to administrators. However, software restriction policies defined in Local Security Policy objects have no way to filter, based on users. In this case, the Skip Administrators option should be used. To turn on Skip Administrators | • | In the Enforcement Properties dialog box, select the following option (as shown in Figure 2). Apply software restriction policies to the following users > All users except local administrators Note Setting the Skip Administrators option is only valid for machine policies. Note In Windows Vista, setting the Skip Administrators option is only valid for elevated applications. For all un-elevated applications, this option will not work as software restriction policies use the (Lower) user account control (UAC) token, which does not contain admin group SID. For more information about UAC, see http://www.microsoft.com/technet/windowsvista/security/uac.mspx |
Enforce Certificate RuleBy default, software restriction policy rules are not enforced against certificate rules because enabling this option results in performance degradation. To Enforce Certificate Rules | • | In the Enforcement Properties dialog box, select the following option (as shown in Figure 2). When applying software restriction policies > Enable certificate rules |
Defining ExecutablesThe Designated File Types dialog box (shown in Figure 3) lists the file types to which the software restriction policy applies. The designated file types are file types that are considered executable. For example, a screen saver file (SCR) is considered executable because when it is double-clicked in Microsoft Windows Explorer, it is loaded as a program. The rules in a software restriction policy only apply to the file types listed in the Designated File Types dialog box. If your environment uses a file type that you want to be able to apply rules to, add it to the list. For example, if you use Perl scripting files, you may choose to add .pl and other file types associated with the Perl engine to the Designated File Types list. .jpg)
Figure 3: Designated File Types Dialog Box Trusted PublishersThe Trusted Publishers options (shown in Figure 4) allow you to configure settings related to ActiveX controls and other signed content. .jpg)
Figure 4: Setting Trusted Publishers Options Table 3 shows Trusted Publisher options related to the use of ActiveX controls and other signed content. | Table 3 Trusted Publisher Tasks and Settings | | Task | Setting | | To allow any user to make decisions regarding signed active content. | To allow all administrators and users to manage the user’s own Trusted Publishers. | | To allow local machine and domain administrators to make all decisions regarding signed active content. | To allow only administrators to manage Trusted Publishers. | | To allow only domain administrators to make decisions regarding signed active content. | To allow only enterprise administrators to manage Trusted Publishers. | | To ensure that the certificate used by the software publisher has not been revoked. | To verify that the certificate is not revoked when adding (recommended). | | To ensure that the certificate used by the organization that time-stamped the active content has not been revoked. | To verify that the certificate has a valid time stamp when adding. |
Scope of Software Restriction PoliciesSoftware restriction policies do not apply to the following: | • | Drivers or other kernel-mode software. | | • | Any program run by the SYSTEM account. | | • | Macros in Microsoft Office 2000 or Office XP documents. | | • | Programs written for the common language run time. (These programs use the Code Access Security Policy.) |
Top of page
Software Restriction Policy DesignThis section covers how software restriction policies are administered using Group Policy snap-ins, things to be concerned about when editing a policy for the first time, and what is involved in applying a software restriction policy to a group of users. Integration with Group PolicySoftware restriction policies are administered using the following Group Policy snap-ins. Domain Policy To set up a domain policy 1. | Click the Start button to open the Group Policy Management snap-in. Click Run, type gpmc.msc, and then click OK. | 2. | Right-click on domain or OU, then click Create a GPO in this domain and link it here… option. | 3. | In the new GPO window, type the name of the GPO, and then click OK. | 4. | Right-click the new GPO, and then select Edit. | 5. | In the Group Policy Object Editor, create new/edit software restriction policies for computer and/or user configuration. |
Local Security Policy To set up a security policy 1. | Click the Start button, and then click Run. | 2. | Type secpol.msc, and then click OK. |
If editing a GPO, you can set User and Machine software restriction policies as shown in Figure 5. .jpg)
Figure 5: Setting User and Machine Software Restriction Policies Local Security Policy In a domain, both user and machines policies can be set in one MMC snap-in, as explained previously. For local security policy, there is no single place where software restriction policies can be set for both user and machine. The following steps show how to set user and machine local security policy. Local Security Policy (Machine) To set up a security policy 1. | Click the Start button, and then click Run. | 2. | Type secpol.msc, and then click OK. |
If you are editing the local security policy, the software restriction policy settings are located as indicated in Figure 6. .jpg)
Figure 6: Editing Local Security Policy Local Security Policy (User) To set up a security policy 1. | Click the Start button, and then click Run. | 2. | Type mmc, and then click OK. | 3. | In the MMC snap-in window, click File, and then select Add/Remove. | 4. | In the Add/Remove snap-in window, select the Group Policy Object Editor snap-in from the list of available snap-ins, and then click Add. | 5. | The Group Policy wizard will be displayed for the local computer. | 6. | Click Browse. The Browse for Group Policy Object window will be displayed. | 7. | Select the Users tab, and then select the user you want to set security policy for. | 8. | In the Group Policy Object window, click OK, and then click Finish. | 9. | In the Add/Remove snap-in window, click OK. | 10. | In the MMC window, expand the tree for Local Computer\User Policy. | 11. | Navigate to user configuration nodeWindows SettingsSecurity SettingsSoftware Restriction Policies node |
If you are editing the local user security policy, the software restriction policy settings are a indicated in Figures 7-12 .jpg)
Figure 7: Editing Local User Security Policy .jpg)
Figure 8: Editing Local User Security Policy .jpg)
Figure 9: Editing Local User Security Policy .jpg)
Figure 10: Editing Local User Security Policy .jpg)
Figure 11: Editing Local User Security Policy .jpg)
Figure 12: Editing Local User Security Policy First-time ConsiderationsThe first time you edit a policy, you will see the message in the result pane as shown in Figure 13. The message is warning you that creating a policy will define default values. These default values can override settings from other software restriction policies. .jpg)
Figure 13: Warning Message When Creating a New Policy To create a policy | • | On the Action menu, select Create New Policies. |
Applying a Software Restriction Policy to a Group of UsersA software restriction policy is delivered through Group Policy to a site, domain, or OU. However, an administrator may want to apply a software restriction policy to a group of users within a domain. To do this, the administrator can use GPO filtering. For more information about GPO filtering, see the Windows Server 2003 Group Policy article at http://www.microsoft.com/windowsserver2003/technologies/management/grouppolicy/default.mspx Terminal ServersSoftware restriction policies are an integral part of securing a Windows Server 2003 terminal server. Terminal server administrators can now thoroughly lock down software access on a terminal server. Software restriction policies are even more imperative on a terminal server because of the potentially vast number of users on a single machine. On a single-user Windows XP client, running a bad application inconveniences only one user, whereas running the same application on a terminal server could inconvenience more than 100 users. Software restriction policies prevent this problem. This service also removes the need for such applications as appsec.exe to govern software execution on a Windows Server 2003 terminal server. In addition, Microsoft recommends that you view 278295 (How to Lock Down a Windows 2000 Terminal Server Session) to further lock down the client sessions on a terminal server. Sometimes, several terminal servers have the same software installed on them, but their administrator wants to grant a certain group of users access to some software and a different group of users access to different software. Some software will be shared between the groups. For example, a law firm hosts its applications across a farm of terminal servers. The servers all have the same software installed. The access rules to the software are as follows: | • | Any employee can use Office and Internet Explorer. All employees are members of the AllEmployees group. | | • | Any accounting employee can use the Accounting Software. Accounting employees are members of the AccountingEmployees group. | | • | Any lawyer can use the Law Research software. Lawyers are members of the Lawyers group. | | • | Any mailroom employee can use the Mail Room Processing software. Mailroom employees are members of the MailRoomEmployees group. | | • | Any executive can access all software available to all other employees. Executives are members of the Executives group. | | • | GPOs do not affect administrators. |
To achieve this software access, the administrator creates five GPOs with customized software restriction policies. Each GPO is filtered so that only the users in the AllEmployees, AccountingEmployees, Lawyers, MailRoomEmployees, and Executives groups receive their intended GPO Because only executives should be able to access any software on their local workstations, as well as on the terminal servers, the administrator uses the loopback feature of Group Policy. The loopback feature allows an administrator to apply policy to a user based on the computer the user is logging on to. In loopback replace mode, the computer GPO settings are reapplied when the user logs on, and the user GPO settings are ignored. For more information about how to configure loopback, see the Group Policy related white papers at http://technet2.microsoft.com/windowsserver/en/whitepapers.mspx. | User GPO: A1 Linked with Law Domain | | | Filter:Law Domain Computers have Apply Group Policy permission | | | Default Security Level | | | Disallowed | | | Path Rules | | | %WINDIR% | Unrestricted | | %PROGRAMFILES%\Common Files | Unrestricted | | %PROGRAMFILES%\Internet Explorer | Unrestricted | | %PROGRAMFILES%\Windows NT | Unrestricted | | %PROGRAMFILES%\Microsoft Office | Unrestricted |
| User GPO: A2 Linked with Law Domain | | | Filter: LawDomain Computers and AccountingEmployees have Apply Group Policy permission | | | Default Security Level | | | Disallowed | | | Path Rules | | | %PROGRAMFILES%\Accounting Software | Unrestricted |
| User GPO: A3 Linked with Law Domain | | | Filter: Law Domain Computers and MailRoomEmployees have Apply Group Policy permission | | | Default Security Level | | | Disallowed | | | Path Rules | | | %PROGRAMFILES%\Mailroom Processing | Unrestricted |
| User GPO: A4 Linked with Law Domain | | | Filter: Law Domain Computers and Lawyers have Apply Group Policy permission | | | Default Security Level | | | Disallowed | | | Path Rules | | | %PROGRAMFILES%\Law Research Software | Unrestricted |
| User GPO: A5 Linked with Lab Resource Domain | | | Filter: Law Domain Computers and Executives have Apply Group Policy permission | | | Enable Loopback in Replace Mode | | | Default Security Level | | | Disallowed | | | Path Rules | | | %PROGRAMFILES%\Law Research Software | Unrestricted | | %PROGRAMFILES%\Mail Room Program | Unrestricted | | %PROGRAMFILES%\Accounting Software | Unrestricted |
Top of page
Step-by-Step Guide for Designing a Software Restriction PolicyThis section outlines the steps to follow when designing a software restriction policy. Items to AddressWhen designing a policy, decisions need to be made regarding the following items | • | GPO or local security policy | | • | User or machine policy | | • | Default security level | | • | Additional rules | | • | Policy options | | • | Linking the policy to a site, domain, or OU |
Stepping Through the ProcessStep 1. GPO or Local Security Policy Should the policy apply to many machines or users in a domain or OU, or should it only apply to the local machine? | • | If the policy should apply to many machines or users in a domain or other Active Directory container, use a GPO. | | • | If the policy should only apply to the local machine, use the Local Security Policy. |
Step 2. User or Machine Policy Should the policy apply to users regardless of where they log in, or to a machine regardless of who logs in? | • | If you want the policy to apply to a specific group of users, for example, the Marketing Department domain group, you need a user policy. | | • | If you want the policy to apply to a set of machines and all the users that log on to those machines, you need a machine policy. |
Step 3. Default Security Level Do you know all the software your users will be running, or can they install any software they choose? | • | If you know all of the software your users will be running, you should set the default security level to Disallowed. | | • | If users can install any software they want, set the default security level to Unrestricted. |
Step 4. Additional Rules Identify the applications you choose to allow or disallow using the four rule types outlined previously in the Software Restriction Policy Architecture section above. | • | To see which rules make sense for your policy, see Table 1. | | • | To create additional rules, see the Step-by-Step Guide for Creating Additional Rules section. |
Step 5. Policy Options Several policy options are available | • | If you are using a local security policy and do not want the policy to apply to administrators on the machine, set the Skip Administrators option. | | • | If you want to check DLLs in addition to executables and scripts, turn on the DLL checking option. | | • | If you want to set rules on file types that are not in the default list of designated file types, then add additional file types. | | • | If you want to change who can make decisions about downloading ActiveX controls and other signed content, set Trusted Publishers options. |
Step 6. Linking the Policy to a Site, Domain, or Organizational Unit To link a GPO to a site 1. | Use the Active Directory Sites and Services snap-in. | 2. | Right-click the site, domain, or OU to which you want to link the GPO, and then select Properties. | 3. | To create, edit, and manage GPOs, click the Group Policy tab |
To link a GPO to a domain or OU 1. | Use the Active Directory Users and Computers snap-in. | 2. | Right-click the site, domain, or OU to which you want to link the GPO, and then select Properties. | 3. | To create, edit, and manage GPOs, click the Group Policy tab |
Filtering GPO filtering can be done at this stage. You can have a portion of an OU receive a GPO by filtering based on group membership. You can also filter based on a WMI query. Testing a Policy If you want to test your policy immediately, instead of waiting for the next Group Policy refresh interval, run gpupdate.exe /force, and then log on again to test your policy. You need to reboot the machine to enforce software restriction policies when Software Restriction Policies are created for the first time. Important You need to reboot the machine to enforce software restriction policies when Software Restriction Policies are created for the first time to test the policy. If you have only one user, logging off would be sufficient to test the policy. However, if you have many users using multiple terminal server sessions. Software restriction policies will not be applied to those active sessions if you just log off. For this purpose, it is recommended that you reboot the machine for the first time when Software Restriction Policies are created, and from then on, gpupdate/force will update the policy. Top of page
Step-by-Step Guide for Creating Additional RulesThe following steps are helpful when creating additional rules. To illustrate the principles behind the steps, each one illustrates an example of creating rules for Office XP. Step 1. List the Software Applications List the software you are trying to identify. For the Office XP example, the software consists of Microsoft Word, Microsoft Excel, Microsoft PowerPoint, and Outlook Step 2. Decide Rule Type See Table 1 to decide which rule type to use. Also, determine the security level for your rule. For the example, path rules set to the Unrestricted security level are used. Step 3. Record the Folders Where the Software Is Installed List the paths where the software is installed. Three ways to do this include: | • | Look at the Target property of a shortcut to the file. | • | Start each program by clicking the Start button, click Run, and then type msinfo32.exe. From msinfo32, select Software Environment, and then select Running Tasks. | | • | Use the following command: wmic.exe process get "ExecutablePath, ProcessID" |
|
For the example, you will see the following tasks running. | • | "C:\Program Files\Microsoft Office\Office10\WINWORD.EXE" | | • | "C:\Program Files\Microsoft Office\Office10\EXCEL.EXE" | | • | "C:\Program Files\Microsoft Office\Office10\POWERPNT.EXE" | | • | "C:\Program Files\Microsoft Office\Office10\OUTLOOK.EXE" |
Step 4. Identify Dependent Programs Some programs launch other programs to perform tasks. Your software application may depend on one or more supporting programs. For example, Word launches Microsoft Clip Organizer to manage clip art. Clip Organizer uses the following programs. | • | C:\Program Files\Microsoft Office\Office10\MSTORDB.EXE | | • | C:\Program Files\Microsoft Office\Office10\MSTORE.EXE |
Office also uses files in the C:\Program Files\Common Files folder. Step 5. Generalize the Rules In this step, you should group related rules to create a more general rule. Consider using environment variables, wild cards, and registry path rules. Continuing the example, each program is stored in C:\Program Files\Microsoft Office\Office10, so it is sufficient to use one path rule for that folder instead of four separate path rules. Also, if Office is always installed in the Program Files folder on your machines, use an environment variable instead of an explicit path. Thus, our proposed rules are: | • | %ProgramFiles%\Microsoft Office\Office10 | | • | %ProgramFiles%\Common Files |
Step 6. Have You Allowed Too Much? In this step, you look at what else is allowed by the rules you have proposed. Creating a rule that is too general may allow programs to run that you did not intend. The Office10 folder in the example also contains: | • | FINDER.EXE | | • | OSA.EXE | | • | MCDLC.EXE | | • | WAVTOASF.EXE |
Because these programs are acceptable to run, the rules do not have to be changed Top of page
Commonly Overlooked RulesWhen designing a policy, consider the following areas when creating rules. Login Scripts Login scripts are stored on a central server. Often, this central server can change each time a user logs on. If your default rule is Disallowed, be sure to create rules that identify the locations of your login scripts. Consider using wildcards to identify these locations if the login servers have similar names. System File Protection System file protection contains backup copies of many system programs in a folder named dllcache. These programs can be started by a user who knows the full path to the backup copy. If you want to disallow users running programs contained in the backup folder, you may want to create the following rule. %WINDIR%\system32\dllcache, Disallowed Common Startup Locations Windows has many locations that contain links to programs that run at start up. If you do not make provisions for these programs, users will receive error messages when they log on.Common startup locations include: Common startup locations include: | • | %USERPROFILE%\Start Menu\Programs\Startup | | • | %ALLUSERSPROFILE%\Start Menu\Programs\Startup | | • | Win.ini, System.ini lines beginning with "run=" and "load=" | | • | HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run | | • | HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce | | • | HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run |
Virus Scanning Programs Most anti-virus software has a real-time scanner program that starts when the user logs on and scans all files accessed by the user, looking for possible virus contamination. Make sure your rules allow your virus scanning programs to run. Top of page
ScenariosThis section examines some typical problems and how software restriction policies can be used to solve them. Block Malicious ScriptsAn organization wants to be protected from script-based viruses. The LoveLetter virus, technically called a worm, was estimated to have caused between 6 and 10 billion dollars in damage. This worm, which has more than 80 variants, continues to be encountered frequently. The LoveLetter worm, written in Visual Basic Script (VBScript) language, is encountered as LOVE-LETTER-FOR-YOU.TXT.VBS. A software restriction policy blocks this worm simply by disallowing any .vbs file from running. However, many organizations use VBScript files for systems management and login scripts. Blocking all VBScript files from running protects an organization, but a VBScript can no longer be used for legitimate purposes. A software restriction policy overcomes this handicap by blocking the undesirable VBScript, while allowing legitimate ones to run. This policy can be created using the rules in Table 4. | Table 4 Rules for Blocking Malicious Scripts | | Default Security Level: Unrestricted | | | Path Rules | | | *.VBS | Disallowed | | *.VBE | Disallowed | | *.JS | Disallowed | | *.JSE | Disallowed | | *.WSF | Disallowed | | *.WSH | Disallowed | | Certificate Rules | | | IT Department Certificate | Unrestricted |
This policy prevents all scripting files associated with the Microsoft Windows Script Host from running, except those that are digitally signed by the IT Department certificate. For information about how to obtain a certificate and digitally sign files, see the Appendix. Blocking Mapped DriveIf you set a disallowed path rule policy to block a drive that is mapped to a file server (\\server\share), software restriction policy does not work. The reason is that when you map a drive to a share, the drive is linked to that share path (\\server\share). Software restriction policy will always resolve the link to the actual share path (in this case \\server\share) and search for any rules that apply to that path (in thhis case \\server\share) not to the mapped drive. Manage Software InstallationYou can configure your organization's machines so that only approved software can be installed. For software that uses Windows Installer technology, this can be accomplished by the policy shown in Table 5. | Table 5 Rules for Managing Software Installation | | Default Security Level: Unrestricted | | | Path Rules | | | *.MSI | Disallowed | | \\products\install\PROPLUS.MSI | Unrestricted | | Certificate Rules | | | IT Department Certificate | Unrestricted |
This policy prevents all Windows Installer packages from installing. It allows MSI files digitally signed by the IT Department certificate and the OWC10.MSI package, located at \\products\install, to be installed. For information about how to obtain a certificate and digitally sign files, see the Appendix. This policy also shows how you can use the precedence of the path and certificate rules to allow only the software you want. For any other package that your organization cannot or does not want to digitally sign, you can create hash rules, or fully qualified path rules, to make exceptions for them. Line-of-Business PCIn some cases, an administrator may want to manage all the software that runs on a machine. This is because even when users have insufficient rights to replace system files or files in shared folders such as Program Files, they can copy a program to a place on the file system that they can write to, and then start that program. Viruses contracted this way can damage the system by modifying operating system settings and files; they can also cause great damage by misusing the user's privileges. For example, mass-mailer worms can be spread by accessing the user's address book and sending e-mail. Even normal users on a system are vulnerable to this kind of attack. As long as users are not administrators on their local machines, the policy in Table 6 protects them from accidentally running malicious code. Because users cannot modify the contents of the Program Files or Windows folders, they can only run software installed by an administrator. | Table 6 Policy for Managing all Software on a Machine | | Default Security Level: Disallowed | | | Apply software restriction policies to the following users | | | All users except administrators | | | Path Rules | | | %WINDIR% | Unrestricted | | %PROGRAMFILES% | Unrestricted |
This policy disallows all software on the user's machine, except that installed in the Windows directory, Program Files directory, or the respective subfolders. It does not apply to administrators. If a user receives a virus attachment in an e-mail, for example, WORM.vbs, the mail program will copy it to the profile directory (%USERPROFILE%) and launch it from there. Because the profile directory is not a subfolder of the Windows folder or the Program Files folder, programs launched from there will not run. If all the programs a user needs are not installed in %WINDIR% or %PROGRAMFILES%, or there are programs in those folders that the administrator does not want the user running, the administrator can make additional exceptions as shown in Table 7. | Table 7 Exceptions for Managing all Software on a Machine | | Path Rules | | | %WINDIR%\regedit.exe | Disallowed | | %WINDIR%\system32\cmd.exe | Disallowed | | \\CORP_DC_??\scripts | Unrestricted | | %HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates \InoculateIT\6.0\Path\HOME% | Unrestricted |
The effects of these exceptions are: | • | Both the command prompt (cmd.exe) and the registry editor (regedit.exe) are disallowed. | | • | An exception is created to allow login scripts to run on the user's machine. | | • | The use of the question mark (?) wildcard allows the rule to match \\CORP_DC_01, \\CORP_DC_02, and others. | | • | A registry path rule is added that allows the anti-virus software on the machine to run. |
Different Policies for Different UsersIn this scenario, there are machines that are shared by many users. The machines have the same software installed on them, but the administrator wants to grant a certain group of users access to some software, and a different group of users access to other software. There also will be software that is shared between the groups. Example A computer lab at a university runs 15 machines with identical software. It runs Office, computer-aided design (CAD) software, and the Microsoft Visual C++ compiler. For licensing reasons, the administrators of the computer lab want to ensure the following: | • | Any student can use Office—all students are members of the AllStudents group. | | • | Any engineering student can use the CAD software—engineering students are members of the EngStudents group. | | • | Any computer science student can use the Visual C++ compiler—computer science students are members of the CSStudents group. |
To achieve the objectives of this scenario, the administrator creates three GPOs with customized software restriction policies. Each GPO is filtered so that only the users in AllStudents, EngStudents, and CSStudents receive the GPO intended for them. Because the students need to receive the policy when they log on to the lab computers, but not when they log on to their personal computers, the administrator uses the Group Policy loopback feature. The loopback feature allows an administrator to apply policy to a user based on the computer the user is logging on to. In loopback replace mode, the machine GPOs are reapplied when the user logs on, skipping the normal user policies. See Tables 8, 9, and 10, and Figure 8. For more information about how to configure loopback, see the Windows Server 2003 Group Policy article at http://www.microsoft.com/windowsserver2003/technologies/management/grouppolicy/default.mspx. | Table 8 A1 Linked with Lab Resource Domain | | User GPO: A1 Linked with Lab Resource Domain | | | Filter: Domain Computers have Apply Group Policy permission | | | Default Security Level | | | Disallowed | | | Path Rules | | |
|