Freigeben über

New UAC Technologies for Windows Vista

  • Artikel

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.

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 (UAC)). When the requestedExecutionLevel is present in the embedded application manifest, it overrides Installer Detection.

Installer Detection only applies to:

  • 32 bit executables

  • Applications without a requestedExecutionLevel

  • 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 like "install," "setup," "update," etc.

  • 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 (UAC).

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 with 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 (https://go.microsoft.com/fwlink/?LinkId=30197).

Patching Applications in a UAC Environment

Microsoft Windows Installer 4.0 was designed with UAC in mind in order 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 (https://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.

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.

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’s 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.

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.

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.

  • Use thread hooks to attach to a higher privilege process.

  • Use Journal hooks to monitor a higher privilege process.

  • Perform dynamic link-library (DLL) injection to a higher privilege process.

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.

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 why 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.

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.

Prior to Windows Vista, many applications were typically run by administrators. As a result, applications could freely read and write system files and registry keys. If standard users ran these applications, they would fail due to insufficient access. Windows Vista improves application compatibility for standard users by redirecting writes (and subsequent file or registry operations) to a per-user location within the user’s profile. For example, if an application attempts to write to C:\Program Files\Contoso\Settings.ini, and the user does not have permissions to write to that directory, the write will get redirected to C:\Users\Username\AppData\Local\VirtualStore\Program Files\contoso\settings.ini. For the registry, if an application attempts to write to HKEY_LOCAL_MACHINE\Software\Contoso\ it will automatically get redirected to HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso or HKEY_USERS\UserSID_Classes\VirtualStore\Machine\Software\Contoso.

The following figure details the virtualization process in Windows Vista. In this example, Denise is an administrator in Admin Approval Mode and Brian is a standard user. Virtualization is comprised of two components: file virtualization and registry virtualization.

Virtualization process

Bb756960.UAC_VirtualizationConceptual(en-us,MSDN.10).gif

Important

While developing Windows Vista programs, to reduce the complexity of virtualized files and registry keys, be sure to embed an application manifest with an appropriate requestedExecutionLevel in order to turn off file and registry virtualization.

Virtualization is only enabled for:

  • 32 bit interactive processes

  • Administrator writeable file/folder and registry keys

Virtualization is disabled for:

  • 64 bit processes

  • Non-interactive processes

  • Processes that impersonate

  • Kernel mode callers

  • Executables that have a requestedExecutionLevel

Virtualization and roaming:

  • Virtualization files/folder and registry keys do not roam

  • Associated with global objects that do not roam

File Virtualization

File virtualization addresses the situation where an application relies on the ability to store a file, such as a configuration file, in a system location typically writeable only by administrators. Running programs as a standard user in this situation might result in program failures due to insufficient levels of access.

When an application writes to a system location only writeable by administrators, Windows then writes all subsequent file operations to a user-specific path under the Virtual Store directory, which is located at %LOCALAPPDATA%\VirtualStore. Later, when the application reads back this file, the computer will provide the one in the Virtual Store. Because the Windows security infrastructure processes the virtualization without the application’s assistance, the application believes it was able to successfully read and write directly to Program Files. The transparency of file virtualization enables applications to perceive that they are writing and reading from the protected resource, when in fact they are accessing the virtualized version.

Note

When you enumerate resources in folders and in the registry, Windows Vista will merge global file/folder and registry keys into a single list. In this merged view, the global (protected) resource is listed along with the virtualized resource.

Important

The virtual copy will always be present to the application first. For example, config.ini is available in \PF\App\config.ini and %LOCALAPPDATA%\VirtualStore\config.ini, and the config.ini in the virtual store will always be the one read, even if \PF\App\config.ini is updated.

The following figure details how global and merged views for virtualized resources are displayed for different users.

Virtualized resources and views

Bb756960.UAC_VirtualizationViews(en-us,MSDN.10).gif

The following is an example of the file virtualization process:

Syed Abbas, a sales representative at Woodgrove Bank, is running as a standard user on a computer that he shares with other sales representatives. Syed often uses a spreadsheet application to update and save a file under the Program Files\SalesV1\ directory: \Program Files\SalesV1\SalesData.txt. Although Program Files\SalesV1\ is protected, the file will be saved successfully from the spreadsheet application's point-of-view because of Windows Vista file virtualization. To achieve this, the file write is redirected to Users\Username\AppData\Virtual Store\Program Files\SalesV1\SalesData.txt. When Syed opens Windows Explorer and browses to the Program Files directory, he will see the global view of the SalesData.txt file

Note

For Syed to discover his virtualized files, he must navigate to the virtual store with the Compatibility files button on the Explorer toolbar.

However, after Stuart Munson, another sales representative, logs on to the same workstation Syed uses, he will not see the file SalesData.txt in the Program Files\SalesV1\ directory. If a different user uses the computer and writes to the \Program files\SalesV1\SalesData.txt file, that write will also be virtualized to that user's virtual store. The files Syed updates and saves will remain independent of the other virtualized files on the computer.

Registry Virtualization

Registry virtualization is similar to file virtualization but applies to registry keys under HKEY_LOCAL_MACHINE\SOFTWARE. This feature permits applications that rely on the ability to store configuration information in HKEY_LOCAL_MACHINE\SOFTWARE to continue to when they are run under a standard user account. The keys and data are redirected to HKEY_CLASSES_ROOT\VirtualStore\SOFTWARE. As in the file virtualization case, each user has a virtualized copy of any values that an application has stored in HKEY_LOCAL_MACHINE.

Registry Virtualization Details

  • Can be turned on/off on individual keys in the Software hive

  • New FLAGS option in reg.exe for key level virtualization control: allows recursive enable/disable of virtualization and control of "open access right policy"

  • ZwQueryKey: programmatically query the virtualization flags for a key

  • Virtualization happens on top of WoW64 redirection

  • Enabled both in the 64-bit and 32-bit registry views: HKEY_USERS\UserSID_Classes\VirtualStore\Machine\Software and HKEY_USERS\UserSID_Classes\VirtualStore\Machine\Software\SYSWOW3264.

  • Most pre-Windows Vista 32-bit apps will use the 32-bit view

Virtualization is intended only to assist in application compatibility with existing programs. Applications designed for Windows Vista should NOT perform writes to sensitive system areas, nor should they rely on virtualization to provide redress for incorrect application behavior. When updating existing code to run on Windows Vista, developers should ensure that, during run-time, applications only store data in per-user locations or in computer locations within %allusersprofile% (CSIDL_COMMON_APPDATA) that have access control list (ACL) settings properly set.

Important

Microsoft intends to remove virtualization from future versions of the Windows operating system as more applications are migrated to Windows Vista. For example, virtualization is disabled on 64-bit applications.

Virtualization Recommendations

Virtualization is intended only to assist in application compatibility with existing programs. Applications designed for Windows Vista should NOT perform writes to sensitive system areas, nor should they rely on virtualization to provide redress for incorrect application behavior. When updating existing code to run on Windows Vista, developers should ensure that, during run-time, applications only store data in per-user locations or in computer locations within %alluserprofile% that have access control list (ACL) settings properly set.

Important

Microsoft intends to remove virtualization from future versions of the Windows operating system as more applications are migrated to Windows Vista. For example, virtualization is disabled on 64-bit applications.

The following list details other file and registry virtualization recommendations:

  • Add an application manifest with an appropriate requestedExecutionLevel for your interactive applications. This will turn virtualization off for the manifested application.

  • Do not use the registry as an inter-process communication mechanism. Services and user applications will have different views of the key.

  • Test your application on Windows Vista: Ensure that processes running as standard user do not write to global namespaces like %systemroot%.

  • For filter driver developers: Check your altitude range (https://go.microsoft.com/fwlink/?LinkId=71503). See File System Filters and fltmc.exe (https://go.microsoft.com/fwlink/?LinkId=71504). These must be higher than FSFilter virtualization.

  • Remember that virtualized resources are per-user copies of global resources.

Access Token Changes

When a user logs on to a Windows Vista computer, Windows looks at the administrative Windows privileges and Relative IDs (RIDs) that the user account possesses to determine if the user should receive two access tokens (a filtered access token and a full access token). Windows will create two access tokens for the user if either of the following is true:

  1. The user’s account contains any of the following RIDs.

    • DOMAIN_GROUP_RID_ADMINS

    • DOMAIN_GROUP_RID_CONTROLLERS

    • DOMAIN_GROUP_RID_CERT_ADMINS

    • DOMAIN_GROUP_RID_SCHEMA_ADMINS

    • DOMAIN_GROUP_RID_ENTERPRISE_ADMINS

    • DOMAIN_GROUP_RID_POLICY_ADMINS

    • DOMAIN_ALIAS_RID_ADMINS

    • DOMAIN_ALIAS_RID_POWER_USERS

    • DOMAIN_ALIAS_RID_ACCOUNT_OPS

    • DOMAIN_ALIAS_RID_SYSTEM_OPS

    • DOMAIN_ALIAS_RID_PRINT_OPS

    • DOMAIN_ALIAS_RID_BACKUP_OPS

    • DOMAIN_ALIAS_RID_RAS_SERVERS

    • DOMAIN_ALIAS_RID_PREW2KCOMPACCESS

    • DOMAIN_ALIAS_RID_NETWORK_CONFIGURATION_OPS

    • DOMAIN_ALIAS_RID_CRYPTO_OPERATORS

  2. The user’s account contains any privileges other than those of a standard user account. A standard user account contains only the following privileges.

    • SeChangeNotifyPrivilege

    • SeShutdownPrivilege

    • SeUndockPrivilege

    • SeIncreaseWorkingSetPrivilege

    • SeTimeZonePrivilege

Note

What privileges the filtered token contain are based on whether the original token contained any of the restricted RIDS listed above. If any of the restricted RIDs were in the token, all of the privileges are removed except:

SeChangeNotifyPrivilege

SeShutdownPrivilege

SeUndockPrivilege

SeReserveProcessorPrivilege

SeTimeZonePrivilege

If no restricted RIDs were in the token, only the following privileges are removed:

SeCreateTokenPrivilege

SeTcbPrivilege

SeTakeOwnershipPrivilege

SeBackupPrivilege

SeRestorePrivilege

SeDebugPrivilege

SeImpersonatePrivilege

SeRelabelPrivilege

The first access token, called the filtered access token, has the previous RIDs (if present) marked as USE_FOR_DENY_ONLY in the access token and the administrative Windows privileges, not listed previously, removed. The filtered access token will be used by default when the user launches applications. The unmodified full administrator access token is then attached to the filtered access token and is used when requests are made to launch applications with a full administrator access token.

More information on RIDs can be found at MSDN (https://go.microsoft.com/fwlink/?LinkId=71494).

More information on Windows privileges can be found at MSDN (https://go.microsoft.com/fwlink/?LinkId=71495).

See Also

Concepts

How UAC Works