Amid the hullabaloo about how intrusive Vistas User Account Control feature will be to the average user, Microsoft has been quietly ramping up the support infrastructure needed to help companies adopt it. eWEEK Labs work with UAC shows that more work lies ahead, however.
With Vistas UAC, Microsoft has finally gotten serious about securing the Windows operating system by limiting a users rights during day-to-day computer usage. UAC also finally brings the Windows operating system up to speed with just about every other major operating system available today.
UAC enables the concept of LUP (Least User Privilege), where users run with limited privileges for the bulk of their interaction with the desktop. User rights are elevated only when necessary to perform certain administrative tasks. By limiting the users normal permissions, there is less attack surface on the operating system and less chance for the user to inadvertently—how should we put this—screw things up.
Under UAC, both administrators and standard (limited rights) users operate with the Standard User security token. When a process requiring elevated permissions is initiated, Vista may ask users to confirm their intention to run the process or ask for administrative credentials to perform the act (depending on the configuration). This interaction—be it a confirmation or a credentialing—occurs in the Secure Desktop, where users cant interact with the desktop, and vice versa—until the questions are answered.
Organizations that have already implemented LUP with current Windows versions will likely have the easiest transition to Vista and UAC, as the hard work of getting users accustomed to limited rights and making applications work correctly with those limited rights has already been done. (And we expect that these organizations will quickly remove the annoying credential request for standard users, replacing it with a stock denial message.)
However, organizations unfamiliar with the LUP concept are likely to disable the UAC feature in Vista altogether—at least for the short term—as they begin the arduous task of evaluating their software stable for security compliance with the new operating system. (Vista is expected to be released by the end of 2006.)
Whether administrators are familiar with LUP or not, they will need tools to configure Vista across the enterprise and to evaluate their applications Vista-proclivity. With Group Policy and the Standard User Analyzer, Microsoft aims to do just that.
In Vista, Group Policy includes nine new policy settings that control the behavior of UAC, and these settings can be applied either in the local GPO (Group Policy Object) or in a Windows Server 2003 domain-based GPO. These settings control whether domain-based and built-in local administrators run by default with the Standard User token or with the Administrator privilege token.
In the former case, the settings determine if admins can simply approve privilege escalation or if they must provide their credentials to run a protected task. Other settings dictate whether standard users have the option to enter administrator credentials or if they are simply denied access.
As long as IT managers are administering GPOs from a Vista-based machine, each of these policy objects can be found at Computer Configuration/Windows Settings/Security Settings/Security Options. Because Vista uses new XML-based ADMX templates with Group Policy, legacy Windows machines cannot edit or take advantage of these new policy settings.
Administrators also can enable virtualization via Group Policy as a catchall for applications that need elevated permissions to write files or registry settings to protected parts of the file system, like the Program Files directory or the HKLM registry hive. Virtualization fools the operating system by instead writing these files or keys to a walled garden in the users directory.
Microsoft views virtualization as a stopgap measure, with good cause. Virtualization does not solve compatibility problems for applications that may require other kinds of elevated permissions that cant be met by faking out the file system. So, while Microsoft ramps up its Vista logo program to teach application developers how to conform to Vistas security parameters going forward, it has been creating tools to help administrators and coders get ready for UAC.
This summer, Microsoft released SUA (Standard User Analyzer), a handy GUI that works with the companys Application Verifier to help developers and administrators understand exactly where legacy applications will run afoul of UAC.
For instance, during tests, when we used SUA to evaluate an application that we knew required some administrative privileges—SysInternals FileMon—SUA alerted us to a few files temporarily copied to a protected disk location, as well as a pair of required administrator privileges that FileMon needs to run (SeDebug Privilege and the SeLoadDriverPrivilege).
Since virtualization is not an option here, and handing out administrative credentials to all application users defeats the value of UAC in the enterprise, administrators must look elsewhere for a solution.
Administrators can deal with offending applications one by one via SUAs Compatibility tab, by clicking on the Run As Program as Administrator button. However, this solution can be unwieldy across a large number of desktops and is not guaranteed to work, as the executable may be blocked from that capability.
Earlier this year, we reviewed a pair of solutions that offer a more elegant approach to policy-based privilege escalation for applications and processes. Both Desktop Standards PMAS (PolicyMaker Application Security) and Winternals Software Protection Manager allow administrators to selectively elevate a processs or applications security privileges according to user, group or host computer. In this way, administrators can allow standard users to run poorly coded applications that require various elevated privileges or attempt to write files or registry settings to restricted areas of the file system via policy without having the user present administrative credentials.
We prefer the PMAS solution because of its tight integration with Group Policy, although we felt Protection Manager had slightly superior rights delegation, filtering and process identification capabilities. But Protection Managers agent architecture proved sluggish and unwieldy in some circumstances, while PMAS snapped right into Group Policy.
Interestingly, Microsoft purchased both companies within the last few months, although PMAS was not included in the Desktop Standard acquisition. Instead, PMAS is now sold and maintained by BeyondTrust, previously a spinoff subsidiary of Desktop Standard, while Microsoft is the proud owner of a series of Group Policy-based configuration and security settings to add to its burgeoning arsenal for the forthcoming Windows Longhorn Server.
Microsoft should be able to meld these technologies into Group Policy to form a powerful solution to help administrators unlock legacy applications in a scalable, organized fashion while it awaits Vista-compliant code from ISVs.
Unfortunately, it is likely too late to see this functionality in the Windows Longhorn Server release time frame. We would hope to see such capability at the top of the list of new features for subsequent Longhorn Server service packs, however.
Technical Analyst Andrew Garcia can be reached at email@example.com.