Window Vista UAC(用户访问控制)

Introduction

This article is intended to assist application developers with designing Windows Vista capable applications that are User Account Control (UAC) compliant. Detailed steps about the design process are included, along with code samples, requirements, and best practices. This article also details technical updates and changes to the user experience in Windows Vista.

Why User Account Control?

Application developers have consistently created Microsoft Windows applications that require excessive user rights and Windows privileges, often requiring that the executing user be an administrator. As a result, few Windows users run with the least user rights and Windows privileges required. Many enterprises, seeking to balance ease of deployment and ease of use with security, have often resorted to deploying their desktops as administrator due to standard user application compatibility problems.

（应用程序开发者一贯地创建要求超过用户权限和Windows特权的应用程序，经常要求创建进程的用户为管理员。因此，很少有Windows用户以最小用户权限和所需的Windows特权来运行程序。许多企业寻找易于部署和易于安全使用的平衡，经常由于标准用户的应用程序兼容性问题，部署他们的应用程序以管理员身份启动。）

The following list details additional reasons it is difficult to run as a standard user on computers running operating systems earlier than Microsoft Windows Vista.

1. Many Windows applications require that the logged on user be an administrator, but these applications do not actually require administrator-level access. These applications perform a variety of administrator access checks before being permitted to run, including:
   1. Administrator access token checks.
   2. "All access" access requests in system protected locations.
   3. Data writing to protected locations, such as %ProgramFiles%, %Windir%, and HKEY_LOCAL_MACHINESoftware.
2. Many Windows applications are not designed with the concept of least-privilege and do not separate user and administrator functionality into two separate processes.
3. Windows 2000 and Windows XP create every new user account as administrator by default; therefore, key Windows components, such as the Date and Time and the Power Management control panels do not work well for a standard user.
4. Windows 2000 and Windows XP administrators must create two separate user accounts—one for administrative tasks and a standard user account to perform day-to-day tasks. Therefore, users must log off their standard user accounts and log in again as an administrator, or use Run As to perform any administrative tasks.

With User Account Control (UAC), Microsoft provides a technology to simplify deploying standard user desktops in the enterprise and at home.

Building off of the Windows security architecture, as originally designed in the Microsoft Windows NT 3.1 operating system, the UAC team sought to implement a standard user model that was both flexible and more secure. In previous versions of Windows, one access token was created for an administrator during the logon process. The administrator's access token includes most Windows privileges and most administrative security identifiers (SIDs). This access token ensures that an administrator can install applications, configure the operating system, and access any resource on the computer.

The UAC team took a drastically different approach to designing the access token creation process in Windows Vista. When an administrator user logs on to a Windows Vista computer, two access tokens are created: a filtered standard user access token and a full administrator access token. Instead of launching the desktop (the Explorer.exe process) with the administrator's full access token, the filtered standard user access token is used. All child processes inherit from this initial launch of the desktop, which helps limit the attack surface of Windows Vista. By default, all users, including administrators, log on to Windows Vista as standard users.

(当管理员用户登录Vista后，两个访问令牌将被创建：一个过滤的标准用户访问令牌和一个完全的管理员访问令牌。与使用完全的管理员令牌登录桌面不同，我们使用过滤的标准用户访问令牌登录桌面。所有的子进程将继承最初登录桌面的访问令牌，这将限制对Vista表面的攻击。默认情况下，所有用户，包括管理员在内，将以标准用户身份登录Vista。)

Note   There is one exception to the preceding statement: Guests log on to the computer with fewer user rights and privileges than standard users.

When an administrator user attempts to perform an administrative task, such as installing an application, UAC prompts the user to approve the action. When the administrator user approves the action, the task is launched with the administrator's full administrator access token. This is the default administrator prompt behavior, and it is configurable in the local Security Policy Manager snap-in (secpol.msc) and with Group Policy (gpedit.msc).

Note   An administrator account on a Windows Vista computer with UAC enabled is also called an administrator account in Admin Approval Mode. Admin Approval Mode identifies the default user experience for administrators in Windows Vista.

Each administrative elevation is also process specific, which prevents other processes from using the access token without prompting the user for approval. As a result, administrator users have more granular control on what applications install while greatly impacting malicious software that expects the logged on user to be running with a full administrator access token.

（每个管理任务的权限提升是进程特定的，这将组织其他进程在未获得用户同意的情况下使用访问令牌。因此，管理员用户对应用程序的安装有着颗粒状的控制，同时对期望登录的用户为拥有完全管理权限的访问令牌的恶意软件有巨大影响。）

Standard users also have the opportunity to elevate within a task flow to perform administrative tasks by using the UAC infrastructure. When a standard user attempts to perform an administrative task, UAC prompts the user to enter valid credentials for an administrator account. This is the default standard user prompt behavior, and it is configurable in the local Security Policy Manager snap-in (secpol.msc) and with Group Policy (gpedit.msc).

（标准用户也可以通过使用UAC基础设施可以在执行管理任务的工作流期间提升权限。当标准用户准备执行管理任务时，UAC提示用户输入管理员账户的有效凭证。这是默认的标准用户提示行为，在LSP管理器和组策略中可以进行配置。）

For detailed information about "Why User Account Control?" see the Windows Help file, which can be downloaded here. To find this article in the Help file, expand Fundamentals, expand Secure Applications, expand Developing Secure Applications, and then click User Account Control (UAC).

How UAC Works

This section describes the architectural and functional components of User Account Control (UAC) for application developers.

New Technologies for Windows Vista

The following sections detail new technologies for Windows Vista, including the ActiveX Installer Service, installer detection, standard user patching with Windows Installer 4.0, Security Center integration, User Interface Privilege Isolation, and virtualization.

ActiveX Installer Service

The ActiveX Installer Service enables enterprises to delegate ActiveX control installation for standard users. This service ensures that routine business tasks are not impeded by failed ActiveX control installations and updates. Windows Vista also includes Group Policy settings that enable IT professionals to define Host URLs from which standard users can install ActiveX controls. The ActiveX Installer Service consists of a Windows service, a Group Policy administrative template, and some changes in Internet Explorer. The ActiveX Installer Service is an optional component, and will only be enabled on client computers where it is installed.

Installer Detection

Installation programs are applications designed to deploy software, and most write to system directories and registry keys. These protected system locations are typically writeable only by administrator users; this restriction means that standard users do not have sufficient access to install most programs. Windows Vista heuristically detects installation programs and requests administrator credentials or administrator approval in order to run with access privileges. Windows Vista also heuristically detects updater and un-installation programs. A design goal of UAC is to prevent installations from being executed without the user's knowledge and explicit consent since installations write to protected areas of the file system and registry.

（UAC的设计目标就是组织安装程序在用户不知情的情况下执行下去以及安装程序向文件系统和注册表的保护区域写数据时获取用户的明确同意。）

Important   When developing new installation programs, much like developing programs for Windows Vista, be sure to embed an application manifest with an appropriate

requestedExecutionLevel

element (see Step 6: Create and Embed an Application Manifest in downloadable Help file). When the

requestedExecutionLevel

is present in the embedded application manifest, it overrides Installer Detection.

Installer Detection only applies to:

1. 32 bit executables
2. Applications without a requestedExecutionLevel
3. Interactive processes running as a Standard User with UAC enabled

Before a 32 bit process is created, the following attributes are checked to determine whether it is an installer:

• Filename includes keywords such as "install," "setup," and "update."
• Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.
• Keywords in the side-by-side application manifest embedded in the executable.
• Keywords in specific StringTable entries linked in the executable.
• Key attributes in the resource file data linked in the executable.
• Targeted sequences of bytes within the executable.

Note   The keywords and sequences of bytes were derived from common characteristics observed from various installer technologies.

Ensure that you thoroughly review the entirety of this document, including "Step 6: Create and Embed an Application Manifest" in the downloadable Help File.

Note   The User Account Control: Detect application installations and prompt for elevation setting must be enabled for installer detection to detect installation programs. This setting is enabled by default and can be configured using the Security Policy Manager snap-in (

secpol.msc

) or with Group Policy (

gpedit.msc

).

General information and an overview of the Microsoft Windows Installer can be found at MSDN (http://go.microsoft.com/fwlink/?LinkId=30197).

Patching Applications in a UAC Environment

Microsoft Windows Installer version 4.0 was designed with UAC in mind to make application installations and patching easier. With the introduction of Windows Installer 4.0, patches can be applied to applications without reinstalling a newer version of the application. This method is ideal when an application is deployed in a per-computer install and patches need to be deployed by a user without requiring an administrator access token. For information about how to create and apply patches to applications, see MSDN (http://go.microsoft.com/fwlink/?LinkId=71492).

Security Center Integration

When UAC is disabled on a Windows Vista computer, the Security Center creates an alert and prompts the user to re-enable UAC. Security Center displays this alert once the computer has been restarted after the UAC setting change.

User Interface Privilege Isolation

User Interface Privilege Isolation (UIPI) is one of the mechanisms that helps isolate processes running as a full administrator from processes running as an account lower than an administrator on the same interactive desktop. UIPI is specific to the windowing and graphics subsystem, known as USER, that supports windows and user interface controls. UIPI prevents a lower privilege application from using Windows messages to send input from one process to a higher privilege process. Sending input from one process to another allows a process to inject input into another process without the user providing keyboard or mouse actions.

(UIPI将具有完全管理员特权的进程与使用低于管理员权限的用户启动的进程隔离开来，阻止低特权的应用程序使用Windows消息将输入从一个进程发送到另一个进程。一个进程向另一个进程发送输入消息将使得进程可以在用户不提供键盘或者鼠标确认的情况下向另一个进程注入输入。)

Windows Vista implements UIPI by defining a set of user interface privilege levels in a hierarchical fashion. The nature of the levels is such that higher privilege levels can send window messages to applications running at lower levels. However, lower levels cannot send window messages to application windows running at higher levels.

（Vista通过分层的方式定义一系列用户接口特权，从而实现了UIPI。分层的本质就是高特权级别的进程可以向低级别的进程发送窗口消息，但是低级别的进程不能向运行在高级别的进程发送窗口消息。）

The user interface privilege level is at the process level. When a process is initialized, the User subsystem calls into the security subsystem to determine the desktop integrity level assigned in the process security access token. The desktop integrity level is set by the security subsystem when the process is created and does not change. Therefore, the user interface privilege level is also set by the User subsystem when the process is created and does not change.

（用户接口特权级别是运行在进程级别中的。当进程初始化时，User子系统调用安全子系统，确定分配在进程访问令牌中的桌面完整性级别。当进程创建的时候，桌面的完整性级别就有安全子系统确定了，并且不会改变。因此，用户接口特权在进程创建的时候由User子系统设定并且不会被更改。）

All applications run by a standard user have the same user interface privilege level. UIPI does not interfere or change the behavior of window messaging between applications at the same privilege level. UIPI comes into effect for a user who is a member of the administrators group and may be running applications as a standard user (sometimes referred to as a process with a filtered access token) and also processes running with a full administrator access token on the same desktop. UIPI prevents lower privilege processes from accessing higher privilege processes by blocking the behavior listed below.

（标准用户身份运行的所有进程，它们的用户接口特权级别一样。UIPI不影响或者改变向特特权级别的应用程序之间的窗口消息传递。当管理组的一个成员以标准用户运行程序（有时候指的是以过滤的访问令牌），并且进程以完全管理员的访问令牌在同一个桌面上运行时，UIPI便开始工作。UIPI通过拦截以下行为，阻止低特权的进程访问高特权级别的进程）

A lower privilege process cannot:

• Perform a window handle validation of higher process privilege.（验证高特权进程的窗口句柄的有效性）
• SendMessage or PostMessage to higher privilege application windows. These Application Programming Interfaces (APIs) return success but silently drop the window message.（向高特权级别的进程SendMessage或者PostMessage。这些API丢弃发送的窗口消息后返回成功）
• Use thread hooks to attach to a higher privilege process.（使用线程钩子附加到高特权级别进程）
• Use Journal hooks to monitor a higher privilege process.（使用日志钩子监控高级别进程）
• Perform DLL injection to a higher privilege process.（向高级别进程注入DLL）

With UIPI enabled, the following shared USER resources are still shared between processes at different privilege levels:

• Desktop window, which actually owns the screen surface.
• Desktop heap read-only shared memory.
• Global atom table.
• Clipboard

Painting to the screen is another action that is not blocked by UIPI. Painting to the screen refers to the process of using the Paint method to display content on an external output—a monitor, for example. The USER/graphics device interface (GDI) model does not allow control over painting surfaces; therefore, it is possible for a lower privilege application to paint over the surface region of a higher privilege application window.

（向屏幕画图是另一个不会被UIPI拦截的行为。向屏幕画图就是是使用画图方法向外部输出比如一个显示器展示内容。USER/图形设备接口（GDI）模型不允许对画图上进行控制，因此，低特权的应用程序可以向高特权级别的进程的画图区域进行画图。）

Note   Because the Windows Shell (the Explorer.exe process) is running as a standard user process, any other process running as standard user can still send the Windows Shell keystrokes. This is the primary reason an administrator account in Admin Approval Mode is prompted for elevation consent when the user initiates an administrative action, such as double-clicking on a setup file or clicking on a button marked with an elevation shield icon.

（Note：由于WindowsShell，即Explorer.exe进程，是一标准用户运行的进程，因此任何以标准用户身份运行的进程都可以向WindowsShell发送WindowsShell键盘敲击命令。这就是当用户初始化一个管理员行为，比如双击安装文件或者点击一个带有权限提升盾牌标志的按钮时，管理同意模式中管理员账户弹出是否同意权限提升对话框的主要原因。）

Virtualization

Important   Virtualization is implemented to improve application compatibility problems for applications running as a standard user on Windows Vista. Developers must not rely on virtualization being present in subsequent versions of Windows.

For detailed information about "Virtualization" see the Windows Help file, which can be downloaded here. To find this article in the help file, expand Fundamentals, expand Secure Applications, expand Developing Secure Applications, and then click User Account Control (UAC).

User Account Control Architecture

The following diagram represents the process flow for executable launches in Windows Vista.

Figure 1. UAC architecture

The following describes the process flow displayed in the UAC architecture diagram and how UAC is implemented when an executable attempts to launch.

Standard User Launch Path

The Windows Vista standard user launch path is similar to the Windows XP launch path, but includes some modifications.

1. ShellExecute() calls CreateProcess().
2. CreateProcess() calls AppCompat, Fusion, and Installer Detection to assess if the application requires elevation. The executable is then inspected to determine its requestedExecutionLevel, which is stored in the executables application manifest. The AppCompat database stores information for an applications application compatibility fix entries. Installer Detection detects setup executables.(CreateProcess调用AppCompat、Fusion和安装器检测来评估应用程序是否需要提权。可执行文件审查存储在应用程序清单中的requestedExecutionLevel。AppCompat数据库存储应用程序兼容性固定入口。安装器检测探测安装的可执行文件。)
3. CreateProcess() returns a Win32 error code stating ERROR_ELEVATION_REQUIRED.（CreateProcess返回ERROR_ELEVATION_REQUIRED）
4. ShellExecute() looks specifically for this new error and, upon receiving it, calls across to the Application Information service (AIS) to attempt the elevated launch.（ShellExecute（）收到这个错误后呼叫AIS，试图提升权限后启动进程）

Elevated Launch Path

The Windows Vista elevated launch path is a new Windows launch path.

1. AIS receives the call from ShellExecute() and reevaluates the requested execution level and Group Policy settings to determine if the elevation is allowed and to subsequently define the elevation user experience.
2. If the requested execution level requires elevation, AIS launches the elevation prompt on the callers interactive desktop (based on Group Policy), using the HWND passed in from ShellExecute().
3. Once the user has given consent or valid administrator credentials, AIS will retrieve the corresponding access token associated with the appropriate user, if necessary. For example, an application requesting a requestedExecutionLevel of highestAvailable will retrieve different access tokens for a user that is only a member of the Backup Operators group than for a member of the local Administrators group.

AIS reissues a CreateProcessAsUser() call, supplying the administrator access token and specifying the callers interactive desktop.

Will UAC Affect Your Application?

Whether or not your application will be affected by UAC depends on the applications current state. In a number of cases, no changes will be necessary to comply with Microsoft Windows® Security requirements. However, some applications, including line of business (LOB) applications, may require changes to their install, function, and update processes to properly work in a Windows Vista UAC environment.

For detailed information about "Will UAC Affect your Application?" see the Windows Help file, which can be downloaded here. To find this article in the Help file, expand Fundamentals, expand Secure Applications, expand Developing Secure Applications, and then click User Account Control (UAC).

Designing Applications for Windows Vista

The following list represents a workflow for designing applications for Windows Vista.

Windows Vista application design workflow

Workflow	Description
Step One: Test Your Application for Application Compatibility.	Test your application for Windows Vista application compatibility. This testing can be easily performed by installing the Standard User Analyzer.
Step Two: Classify Your Application.	Classify your application as a standard user, administrator, or mixed user application. Administrative applications in Windows Vista often have a mixture of both administrative and standard user functionality.
Step Three: Redesign for UAC Compatibility.	Redesign your applications functionality for UAC compatibility. Use the information in this section, once you have classified your application and determined whether it must be redesigned for UAC.
Step Four: Redesign Your UI for UAC Compatibility.	Redesign your application user interface. Closely adhering to these guidelines in your applications development will ensure that your application will have a consistent and predictable user experience in Windows Vista.
Step Five: Redesign Your Installer.	Redesign your application installer. The best practices in this section are for well-behaved application installations in a Windows Vista or UAC environment.
Step Six: Create and Embed an Application Manifest.	Create and embed an application manifest with your administrative applications. The correct way to mark your applications is to embed an application manifest within your program that tells the operating system what the application needs.
Step Seven: Test Your Application.	Test your redesigned or new application for application compatibility using the Standard User Analyzer.
Step Eight: Authenticode Signature.	Sign the application with an Authenticode signature to prevent tampering with the executable.
Step Nine: Windows Vista Logo Program.	Participate in the Windows Vista Logo Program.

For detailed information about "Designing Applications for Windows Vista" see the Windows Help file, which can be downloaded here. To find this article in the Help file, expand Fundamentals, expand Secure Applications, expand Developing Secure Applications, and then click User Account Control (UAC).

Impact of UAC on the Windows User Experience

The biggest and most immediate impact on the user experience will be felt by administrators. Administrator users will now need to provide permission to accomplish administrative tasks. Coupled with that, standard users will now gain the ability to perform administrative tasks within the currently logged in session by providing valid administrator credentials.

Goals of the UAC User Experience

The overall goal for UAC user experience is to provide predictability.

• For an administrator, this means that the user always know when he/she will need to give permission to run an elevated task.

This is the act of requesting the user's own administrator access token so that he/she can make administrator-required changes.

• For standard users, this means that they will know when they:
  • Will need to provide administrator credentials (home and unmanaged environments) for administrative tasks.
  • OR when they cannot complete a task (managed environments where elevation is explicitly disallowed) and must contact the help desk.

Elevation Prompt

The elevation prompt is built upon an existing Windows user interface. The elevation prompt displays contextual information about the executable requesting elevation, and the context is different depending on whether the application is Authenticode signed. The elevation prompt is seen in two variations: the consent prompt and the credential prompt.

Consent Prompt

The consent prompt is displayed to administrators in Admin Approval Mode when they attempt to perform an administrative task. This is the default user experience for administrators in Admin Approval Mode and can be configured in the local Security Policy Manager snap-in (secpol.msc) and with Group Policy.

The following illustration is an example of a User Account Control consent prompt.

Figure 2. User Account Control consent prompt

Credential Prompt

The credential prompt is displayed to standard users when they attempt to perform an administrative task. This is the default user experience for standard users and can be configured in the local Security Policy Manager snap-in (secpol.msc) and with Group Policy.

The following illustration is an example of a User Account Control credential prompt.

Figure 3. User Account Control credential prompt

Deploying and Patching Applications for Standard Users

This section discusses how to ensure that your application can be deployed for standard users. For detailed information about "Deploying and Patching Applications for Standard Users," see the Windows Help file, which can be downloaded here. To find this article in the help file, expand Fundamentals, expand Secure Applications, expand Developing Secure Applications, and then click User Account Control (UAC).

Troubleshooting Common Issues

This section lists common development and installation issues that arise in Microsoft .NET applications. For detailed information about "Troubleshooting Common Issues," see the Windows Help file, which can be downloaded here. To find this article in the help file, expand Fundamentals, expand Secure Applications, expand Developing Secure Applications, and then click User Account Control (UAC).

References

This section includes a virtualization reference and a security settings reference. For detailed information about "Virtualization Reference," see the Windows Help file, which can be downloaded here. To find this article in the help file, expand Fundamentals, expand Secure Applications, expand Developing Secure Applications, and then click User Account Control (UAC).

Conclusion

With User Account Control (UAC), Microsoft has provided a technology designed to simplify deploying standard user desktops in the enterprise and at home.

Building off the Windows security architecture, the UAC team sought to implement a standard user model that is both flexible and more secure.