| Downloads |
|---|
| 98964.zip |
|
Executive Summary: Many enterprise users operate workstations, PCs, or laptops as administrators, which is a substantial security risk. Learn how software restriction policies (SRPs), their little-known security levels that produce restricted access tokens, and the Runas command can allow users to remain productive while limiting exposure to high-risk programs and malicious code. |
It's commonplace in today's enterprises for users to operate as administrators on their desktop computers. Allowing users unlimited computer access poses a huge security risk, including potentially letting users inadvertently install or download destructive code and unsupported and dangerous applications. Microsoft developed software restriction policies (SRPs, aka Safer) to let administrators block user access to suspected hostile code and applications. However, SRPs' default settings are overly restrictive for effective desktop management. I'll show you how to use some additional, little-known SRP security levels that generate restricted access tokens to keep your users' computers safe, while still giving users enough flexibility to be productive. First I'll give you some background on SRPs. Then I'll dig into SRPs' little-known additional security levels. Finally, I'll show you how to keep your desktops safe without hampering your users' ability to run their important applications by applying restricted access tokens to high-risk processes using SRPs.
SRP Basics
Microsoft introduced the SRP feature in Windows Server 2003 and Windows XP Professional. Today's collaboration tools, email, IM, and peer-to-peer networking have greatly increased the likelihood that malicious code will find its way into enterprise networks. SRPs control which applications are allowed on a given system by using Group Policy–defined security level rules and exceptions to allow or disallow programs and scripts to run.
SRPs have two default security levels—Unrestricted and Disallowed. The Unrestricted security level assigns tokens to processes with the same privilege level as the logged-on user, simply letting the application run normally. The Disallowed security level denies the user access to applications. However, the Disallowed security level isn't the only way to restrict applications.
Other methods for running applications with restricted and elevated privileges, such as the Runas command, execute the process in the context of a different security principal. (For more information about Microsoft's well-known security principals, see "Understanding Well-Known Security Principals, Part 1," at http://windowsitpro.com/windowssecurity/article/articleid/47857.) Doing so can cause undesired side effects. Consider the following example, where administrative User A wants to use standard User B's account to run Internet Explorer (IE) with reduced privileges:
- User A uses the Runas command to start IE with User B's account.
- User A authenticates with User B's credentials, and IE successfully starts.
- User A tries to download a file from the Internet and save it to a network share.
- User B doesn't have access to the network share, so IE fails to save the file.
Of course, there are ways around this dilemma. For instance, you could give User B permission to access the network share, but using the Runas command and implementing such workarounds aren't realistic solutions in most cases. If you don't want to rely on workarounds and Band-Aid solutions, using Group Policy and SRPs to establish a systemwide plan makes more sense. But SRPs' limited default options can also cause problems.
All-or-Nothing Policies
SRPs' restrictive, all-or-nothing default policies can significantly hamper users' ability to work productively. When Disallowed is enforced, an SRP can keep users from running a potentially high-risk application, such as IE, by setting Disallowed on iexplore.exe, but doing so might reduce productivity to zero. When Unrestricted is enforced, administrative users can open or install any program they want, effectively nullifying an SRP's protections.
The ability to manually assign exceptions that SRPs provide only slightly improves their flexibility. The exceptions let administrators control the programs and scripts that will defy users' default security levels—allowing access to designated applications when Disallowed is enforced and denying access when Unrestricted applies. Having all-or-nothing defaults means the administrator is stuck with Allowed or Disallowed for all programs, which reduces the effectiveness of SRPs. However, there are additional security levels hidden inside SRPs that you can use to tailor their protections to your needs.
Hidden Treasures
A closer look at SRPs reveals that they have three additional, relatively unknown security levels—Basic (also known as standard) user, Constrained, and Untrusted. Using these "secret" levels to generate restricted access tokens will give you much more flexibility to balance security and productivity.
Basic User is the most useful of the additional security levels and provides an acceptable balance between usability and security, because it runs with privileges that are assigned to the User's group, which is the recommended level of security for everyday tasks. The Constrained and Untrusted levels cause most applications to either run with severe functionality limitations or fail completely. Some of the Constrained and Untrusted restrictions include
- no write access to the registry, even the users' own registry section (HKEY_CURRENT_USER)
- no access to the My Documents or Temporary Internet Files folders
- no access to Secure Sockets Layer (SSL) sites
As you can imagine, such restrictions are too limiting for everyday use. They might be useful for using applications, such as IE, to access known vulnerable sites but not as an acceptable day-to-day solution.
To enable Basic User, assuming you're using XP Pro and that your machine isn't in a domain, open Local Computer Policy and log on as an administrator. Then open the Start Menu and select Run. Next type
gpedit.msc
and click OK. Then expand Computer Configuration to include Security Settings, and right-click Software Restriction Policies. Select Create New Policies from the menu, expand Software Restriction Policies, and click Security Levels. In the Group Policy Management Console (GPMC) right pane, you'll see the two default security levels listed—Disallowed and Unrestricted. To add Basic User, you'll need use Regedit to add a DWORD value called Levels, with a value of 0x20000, to the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\MicrosoftWindows\Safer\CodeIdentifiers registry key.
If you don't want to manually edit the registry, you can automatically add the registry value by running basicuser.reg on your computer. (To download basicuser.reg, click the Download the Code button at the top of this article.) A word of warning: Before modifying a computer's registry, always make sure you have a working backup of it.
When you've edited the registry, close GPMC, then reopen it. Navigate back to Software Restriction Policies and the Security Levels option, and you'll see Basic User added to the list, as Figure 1 shows. Now we'll see how you can use Basic User to create a restricted access token to provide effective computer security without a significant productivity decline.
SRPs and Restricted Access Tokens
Restricted access tokens are created by the Local Security Authority (LSA) when a user authenticates. A token includes a user SID, SIDs for all groups to which the user belongs, and the user's privileges. When a thread or process interacts with a securable object or tries to perform a system task, the OS checks the access token to determine its authorization level. (For more background information about access tokens, see "How Access Tokens Work," at http://technet2.microsoft.com/windowsserver/en/library/d06a5070-2a7b-4e75-b7e9-ebe51f65e34b1033.mspx.)
Running high-risk applications with restricted access tokens is useful when you can't remove a user's administrator privileges for political, cultural, or operational reasons. Configuring SRPs to issue restricted access tokens to high-risk applications can provide something of a compromise.
To see the benefit of running applications with restricted access tokens, let's set up a typical example scenario in which a user logs on as an administrator. Every application the user runs executes with the user's privilege level. When an application is launched with a restricted token, the software continues to run, but in the context of the security level defined in the SRP, with a reduced set of privileges for that application.
To see how to use Basic User to run an application with a restricted token, let's configure a path rule for iexplore.exe. Navigate back to the Software Restriction Policies options, right-click Additional Rules, then select New Path Rule. In the New Path Rule dialog box, browse to iexplore.exe or manually enter the path in the Path box. Then set the security level to Basic User, as Figure 2 shows, and click OK. Now open a command prompt and run the following command, which refreshes Group Policy to apply the new SRP setting:
gpupdate /force
While remaining logged on as an administrator, open IE. If everything is working, IE should be running with a restricted token. To perform a quick test, load a Web page and try and save it to a directory to which standard users don't have write permission, such as the Windows directory. If you try to save an IE Web page to the Windows directory, IE should report that access was denied.
You can use Process Explorer, a Windows Sysinternals utility, to display more precise information about an application's privilege level. Process Explorer is essentially an advanced Task Manager replacement. You can download Process Explorer for free at http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx.
Once you've downloaded and installed Process Explorer (procexp.exe), run it, and a list of running processes will be displayed, as Figure 3 shows. Find the iexplore.exe process on the list, right-click it, and select Properties. A new dialog box will appear showing the properties for the iexplore.exe process. Click the Security tab, and you'll see that most user privileges have been removed, and the BUILTIN\Administrators flags are set to Deny, Owner, as Figure 4 shows. Compare this result with Figure 5, which shows IE running in the Unrestricted security level.
So far, I've concentrated on SRPs and restricted access tokens as the sole method of limiting application access. However, the Runas command offers even more flexibility when used with SRPs in the Basic user security level.
Alternate Ways to Use Access Tokens
Once the Levels DWORD value is added to the registry, you can use an alternative to an SRP for starting an application with a restricted token. You can use the Runas command to configure shortcuts that launch applications with different security levels. Consider a situation when you want a user to run IE mostly as Basic User, but you must provide some means for the user to run the application so that he or she can install ActiveX controls. If no SRP has been configured to run an application as Basic User, you can use the Runas command with the /trustlevel switch set to Basic User to launch a process with a restricted token, as the following example shows:
runas /trustlevel:"Basic User" notepad
This command launches the notepad.exe process with a restricted token. If you've configured an SRP to run an application as a Basic User, you can use the Runas command to change the security level back to unrestricted, as the following example shows:
runas /trustlevel:"Unrestricted" "c:\program files\internet exploreriexplore.exe"
Using the previous Runas command, you could create a hidden shortcut to which users can be directed should they need to run IE with the same privileges as their administrative user account.
SRPs' hidden security levels are less hidden in Windows Vista. The Basic User security level is in Vista by default, so you don't need to modify the registry to enable this level. However, you're less likely to use Basic User in Windows Vista, as the Vista User Account Control (UAC) feature makes it realistic for users to work at the standard user level.
When to Run Basic User
In organizations that grant users administrative privileges, I advise you to use Basic User for all compatible software, paying special attention to Internet-facing applications such as IE and Microsoft Office Outlook but also Office-suite programs where files are often shared between users. Make sure you test all applications run as Basic User for compatibility with Windows' security model. For instance, when running IE as Basic User, the user won't be able to install ActiveX controls.
I'd advise creating a path rule for %programfiles% with a Basic User security level, then making application-specific rule exceptions if required. If the Basic User security level and application-specific rules are tested and implemented properly, users might not try to evade such restrictions. For stricter enforcement, you could consider using hash rules, which I explain in the sidebar "Introduction to Software Restriction Policies" (http://www.securityprovip.com, InstantDoc ID 98965).
The Safer Basic User security level is a workaround to the problem of implementing least privilege in XP. It's the next best thing to actually logging on with a standard user account. In XP, elevating privilege level is clumsy at best, so the ability to run software with a restricted token provides a middle ground for users in organizations where it isn't possible to comprehensively employ least privilege.
Why Not Elevate Privileges?
One has to ask why Microsoft offered the ability to restrict privileges for a given process but not the ability to elevate privileges. When Microsoft purchased Desktop Standard in 2006, Microsoft didn't acquire the PolicyMaker Application Security product, which is now sold by BeyondTrust as Privilege Manager (http://www.beyondtrust.com/products/PrivilegeManager.aspx). The software lets you use Group Policy to configure processes to run with elevated privileges. Although this also isn't a perfect solution, it does let you run standard user accounts and configure processes to launch with elevated privileges without having to implement time-consuming workarounds.
The use of SRPs is a workaround when you have users who can log on to their machines as administrators. The best policy is to set up users with standard user accounts. But when you have to use SRPs' protections to keep hostile code and unsupported dangerous applications out of your IT assets, SRPs' hidden security levels and restricted access tokens can keep your workers happy and productive while providing a shield against malicious invaders.