We're all anxiously awaiting Microsoft's official release of the oft-delayed Windows Vista. In the meantime, Microsoft has released several interim builds of the OS, including the full-featured Vista Community Technology Preview (CTP). In this version, we got our first real look at the new security features and tools that Microsoft plans to include in Vista. One of the most fundamental security changes will be the OS's new least-privilege support, embodied in the User Account Control (UAC) feature. In earlier Vista beta releases, UAC was called Least-Privileged User Account.
In my article "Learn to Be Least" (October 2005, InstantDoc ID 47622), I defined least privilege and showed you how to better honor it in Windows XP. The principle of least privilege states that you should give a user or a piece of code only the privileges it needs to do a job—nothing less, and certainly nothing more. Malicious code can do much more harm when it executes in the security context of a highly privileged account, and highly privileged processes can do much more harm when they're compromised or simply buggy.
Now that Vista is on the horizon, it's time to re-evaluate the concept in light of some new functionality that promises to make it easier for all of us to better honor least privilege. Let's look at how least privilege has evolved, then dive into the new Vista features, including UAC and Admin Approval Mode (AAM), which provide Windows with a more behavior-based dynamic.
Problems Till Now
The problem with XP and earlier OSs is that they require a lot of user discipline to honor least privilege, from both users and administrators. For example, XP administrators who want to honor least privilege must create two accounts: a simple user account (aka a limited account) and an account with administrator-level privileges (aka a privileged account). Then, they must have the discipline to use the limited account to perform their day-to-day work—surfing the Web, reading email, working with Microsoft Office documents—and switch to their higher-privileged account only to perform administrative tasks.
True, in XP and Windows 2000, Microsoft made it easier to switch between logon sessions, but it's still far easier for administrators to use one privileged account to do all their day-to-day work. Using a single account also means the administrative user must remember and maintain only one set of credentials. In XP and Win2K, Microsoft effectively integrated least-privilege tools such as the Secondary Logon service, Fast User Switching (FUS), and the Runas command into the Windows UI. (For more information about these improvements, see "Learn to Be Least.")
The bigger problem is that not only XP administrators but also simple XP users typically use a single account with administrator-level privileges. Working with a limited account in XP can be a frustrating experience because the OS doesn't allow limited user accounts to perform simple administrative tasks such as changing a system's time zone settings, installing additional fonts, or changing power-management options. For this reason, administrators often end up granting simple users administrative privileges. Figure 1 shows the XP warning message that appears when a limited-account user attempts to change the system time.
The bottom line is that average XP users and administrators who value ease of use more than security and who don't want to switch back and forth between two user accounts leave their system open to a wide range of attacks. And let's be honest: How often have you used the built-in local administrator account to log on to your standalone XP workstation?
Redefining Limited Accounts
A fundamental Vista change is that Microsoft has redefined what a limited account can and can't do. For example, Vista lets a limited-account user change the system's time and time zone settings, change display properties, install additional fonts, and change power-management options. This modification essentially removes the need for the Power Users group, which Microsoft has eliminated from Vista. Examples of Vista tasks that still require a privileged account are software installation and disk repartitioning.
Also in Vista, every account—even the built-in administrator account and other administrator-level privileged accounts—initially has only limited user privileges. During logon sessions, users can elevate their privileges to the administrator level when necessary, as I explain later. Starting with Vista Beta 2, this functionality is standard Vista behavior because UAC is enabled by default.
Administrator accounts with initially limited user privileges are possible thanks to a change that Microsoft has made in Vista—specifically, the process of creating access tokens for privileged-account users. An access token contains a user's privileges and is attached to a user-logon session. When a privileged-account user logs on to Vista, the OS creates a filtered token that contains only the user's limited-account privileges and is the user's default token during the logon session. Vista can temporarily expand the filtered token to a full token when the user needs to perform an administrative task or launch an application that requires privileged access. The full token contains all the user's privileged-account privileges.
Redefining Administrative Actions
In Vista, Microsoft has clarified which actions require administrator-level privileges and which don't: All operations that require administrator-level privileges are designated by a shield icon, as Figures 2 and 3 show. Figure 2 shows Vista's Date and Time Properties dialog box. Note that only the Change Date and Time button requires administrator-level privileges; any user can change the time zone settings. Figure 3 shows the Vista System dialog box. As with XP, both changing a computer's name and Windows activation require administrator privileges; Vista, however, marks both actions with the shield icon. Windows administrative buttons that are marked with a shield icon are also called unlock buttons.
In typical enterprise environments, only Help desk personnel will use unlock buttons—for example, when they need to control desktops remotely. In typical home environments, only parents will use the unlock buttons—for example, to make configuration changes for children. With Vista, a Help desk operator or parent can, for example, unlock a Control Panel applet without an employee or child needing to log off first. (This kind of operation is also known as an over-the-shoulder administrative task.) Limited-account users and children can't use an unlock button because they don't know the password of privileged accounts.
When a user clicks an unlock button, selects an action that requires administrator privileges, or starts an installation program that requires administrator privileges, Vista will behave differently depending on whether the user is a limited-account or privileged-account user. If the user is a limited-account user, Vista prompts for alternate administrator credentials; if the user has administrator-level privileges, Vista prompts for consent. Figures 4 and 5 show the dialog boxes that Vista displays when a limited-account user and a privileged-account user, respectively, attempt to change the system date and time.
- In the dialog box that Figure 4 shows, a limited-account user can select one of the system's administrator-level accounts and enter the administrator credentials, or can cancel the privilege-escalation action.
- In the dialog box that Figure 5 shows, a user with administratorlevel privileges can express his or her consent by simply allowing or cancelling the action.
Vista's Group Policy Objects (GPOs) include settings that let administrators change the default Vista prompt behavior for limited-account and privileged-account users. You'll find the UAC-related GPO configuration settings—which begin with the words "User Account Control"—in the Security Settings\Local Policies\Security Options GPO container.
Microsoft refers to this privilegeelevation prompt-based behavior as AAM. Thanks to AAM, users and administrators can honor least privilege in a single logon session. Switching back and forth between limited-account user and privilegedaccount user logon sessions is no longer necessary.
Credential or consent dialog boxes such as the ones that Figures 4 and 5 show can appear multiple times during a user's logon session, appearing whenever a user chooses an action marked with a shield icon. Vista doesn't remember previous elevations to administrator-level privileges. The elevated privileges that are linked to a particular task (e.g., new software installation) automatically expire when the task is finished. For this reason, AAM significantly reduces the Vista attack surface. AAM also presents an important advantage for administrative users, who can now— rest assured—perform their day-today work as regular users and switch to administrative privileges only as necessary or when prompted.
Process Isolation
An important hidden UAC feature that also significantly reduces the Vista attack surface is User Interface Privilege Isolation. UIPI provides process isolation by ensuring that processes running in the security context of a limited-account user can't interfere with processes running in the security context of a privileged-account user.
UIPI protects against shatter attacks, during which malicious mobile code (e.g., worms, viruses, Trojan horses) running in the security context of a limited-account user leverages the Windows interprocess messaging system to inject malicious code into a process that runs in the security context of a privileged-account user. In previous Windows versions, shatter attacks are possible because any process can send a message to any other process running on the same desktop (Windows doesn't provide source authentication for interprocess messages) and because, too often, applications are written to run in the security context of privileged-account users. For more information about UAC process isolation and UIPI, see the Microsoft article "Developer Best Practices and Guidelines for Applications in a Least Privileged Environment" (http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dnlong/html/accprotvista.asp).
Applications and UAC
So far, I've discussed only users and administrators, and how UAC affects them. But not only certain user and administrator actions require administrative privileges; certain applications also require higher privileges to function properly. Vista supports several mechanisms that mark an application as requiring runtime administrative privileges:
- Based on a given application's properties, Vista automatically classifies certain applications as requiring runtime administrative privileges. For example, setup or installation applications are automatically marked as requiring administrative privileges.
- During application development, a developer can mark an application as requiring runtime administrative privileges. He or she does so in the application's manifest file. For a complete set of developer guidelines for building UAC-compliant applications, see "Developer Best Practices and Guidelines for Applications in a Least Privileged Environment."
- An administrator can install an application-compatibility shim on a Vista machine that marks an application as requiring runtime administrative privileges. With this approach, an administrator can let a legacy application start with administrative privileges without making code changes. To learn more about installing an application-compatibility shim, see the Microsoft article "Understanding and Configuring User Account Control in Windows Vista Beta 2" (http://www.microsoft.com/technet/windowsvista/deploy/appcompat/acshims.mspx). To test your legacy applications for privilege concerns, Microsoft provides a new version of the Application Verifier tool. You can download Application Verifier 3.2 from http://www.microsoft.com/downloads/details.aspx?FamilyID=bd02c19c-1250-433c-8c1b-2619bd93b3a2
Applications that require administrator-level privileges are marked with the shield symbol, on top of their standard application icon in the Vista interface, as Figure 6 shows.
Independently of whether an application is marked as requiring runtime administrator-level privileges, users can request to start an application in the security context of an administrator account. Figure 7 shows how users can request that Vista start a program in the security context of a privileged account a single time by selecting Run as administrator in the program's context menu. (This menu appears when you right-click the program icon.)
Users can also configure an application to always run with administrative privileges: Simply select the Run this program as an administrator check box on the Compatibility tab of the application's Properties, as Figure 8 shows. Both limited-account and privileged-account users can access these options. Note that selecting Run this program as an administrator doesn't change Vista's AAM behavior: The system will still prompt limited-account users for administrative credentials and privileged-account users for consent.
File System and Registry Virtualization
Vista can deal transparently with applications that aren't marked as requiring runtime administrator privileges and that must write to a registry or file system location that requires administrator-level access privileges. This functionality is possible thanks to the UAC's file-system and registry virtualization features. UAC will transparently create the data an application requires in a file system or registry location that's accessible by using limited-account user privileges. UAC virtualization also automatically redirects applications to the virtual locations when applications must retrieve or write data.
- For registry virtualization, UAC uses the HKEY_USERS\User_SID_Classes\VirtualStore registry container. Registry virtualization works only for applications that attempt to access the HKEY_LOCAL_MACHINE\SOFTWARE registry container.
- For file-system virtualization, UAC uses the %localappdata%\ virtualstore file system folder. File-system virtualization works only for applications that attempt to access the \%systemroot% or \%programfiles% file-system folders.
UAC virtualization should be considered neither the final nor the ultimate solution for resolving legacy application UAC compatibility issues. Some applications simply might not tolerate virtualization and could stop working properly on Vista. Also, we can't assume that Microsoft will include UAC virtualization support in future OS versions. These are two important arguments for motivating your application developers to make their applications function correctly in the security context of limited user accounts or to mark certain applications as requiring administrator privileges.
Big Change!
Clearly, UAC's least-privilege feature will have a big impact on all Vista users: simple users, administrators, and even application developers. UAC is another Windows feature that promises to provide more proactive out-of-the-box security—similar, for example, to Windows Firewall, which is enabled by default in Windows XP Service Pack 2 (SP2) and later. The net effect of UAC is that users will have to make fewer efforts to run Windows securely. The same can't be said, however, for administrators and developers. Features such as AAM might lead privileged-account users to credential fatigue. In Vista, a lot of responsibility definitely lands on developers' shoulders: They need to ensure that both new and legacy applications run properly and behave correctly on Vista.
