Secure Your Desktops Using SRPs’ Hidden Security Levels

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:

1. User A uses the Runas command to start IE with User B's account.
2. User A authenticates with User B's credentials, and IE successfully starts.
3. User A tries to download a file from the Internet and save it to a network share.
4. 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 . . .