How the Integrity Mechanism Is Implemented in Windows Vista
The Windows integrity mechanism is used in a number of ways in Windows Vista. Its main purpose is to restrict the access permissions of applications running under the same user account that are less trustworthy. The mechanism prevents less trustworthy code from modifying objects at a higher level. Most objects under the control of the Administrators group or System have a discretionary access control list (DACL) that typically grants full control permission to Administrators and to System, and read and execute permission to authenticated users. Examples of resources under control of the Administrators group and System are the Program Files directory for applications or the HKEY_LOCAL_MACHINE hive of the registry. The integrity mechanism does not enhance the security of objects that are already properly configured to restrict different user accounts or groups from accessing them. The integrity mechanism's primary purpose is to address different permissions for programs to access resources under the full control of the same user security principal.
The resources under the control of the same user security principal that need additional protection are primarily under the user’s profile (C:\Users\<username> directory and HKEY_CURRENT_USER hive in the registry) and the application programs currently running on behalf of that user. Windows Vista uses the integrity mechanism in the following ways.
- In UAC, it limits access between processes running with standard user privilege and elevated processes running with full administrative rights in Admin Approval Mode.
- COM security is aware of integrity levels and does not allow lower-integrity clients to bind to class instances running at a higher integrity level.
- In the default security settings, it restricts access to the root folder of the system volume.
- In Protected Mode Internet Explorer, it limits the ability of code running in the Internet browser to modify user data or user profile settings.
- To enable applications running at low integrity to have a writeable file location, it assigns specific folders in the user profile a low integrity level.
The integrity mechanism is part of the Windows Vista security architecture. Over time, specific applications that handle untrustworthy input (primarily Internet-facing) are updated to take advantage of the ability to run at a low integrity level. Personal productivity applications are fine running at a medium integrity level as long as the users knows the source of input data. For most applications, the integrity mechanism is completely transparent and does not interfere with application features. Application services can be updated to provide better isolation of server resources for client processes at different integrity levels.
Integrity levels and UAC
UAC in Windows Vista runs multiple programs at different levels of access on the same desktop when using Admin Approval Mode. Programs have different privileges based on the security access token assigned to the process when the process is created. Users with accounts that are standard users have only one security access token created during logon. The standard user access token is assigned a medium integrity level. The medium integrity standard user access token is assigned to almost all application processes that user runs. Specific applications, such as Protected Mode Internet Explorer, are an exception that is described further below.
Users with accounts that are members of the Administrators group have two security access tokens created at logon that are linked together. One access token is a standard user access token assigned a medium integrity level, which has the Administrators group used for Deny access checks only, and certain administrative privileges removed. The second access token is a full-privilege, elevated-access token that is assigned a high integrity level because the Administrators group and administrative privileges are present in the access token. The access tokens are linked because they are related to the same interactive logon for that user account. Both access tokens have the same user SID and the same global groups from Active Directory (except the filtered groups for Domain and Enterprise Admin).
The Windows Explorer (also known as the shell) and all non-administrator tasks are assigned the standard user, medium-integrity access token. For the user account that is a member of the Administrators group, almost all applications are run with the medium-integrity access token. The NO_WRITE_UP integrity policy does not restrict the access permissions of medium-level processes to access objects that have an implicit medium object mandatory label. The integrity mechanism is transparent to applications at medium integrity level, unless they are designed to control other processes that may be running at a higher privilege level. Windows UI Automation is an example of an application that is designed to control other processes.
UAC Admin Approval Mode allows the user to launch administrative tasks and applications after providing consent with the full-privilege, elevated-access token. The operating system must restrict the ability of the lower privilege (standard user) process to tamper directly with the higher-privilege (Administrator) process running under the same user SID. The Windows integrity mechanism limits the access permissions that the medium-integrity process can have on the high-integrity process. The process manager (part of the Windows kernel) assigns the mandatory policy options NO_READ_UP and NO_WRITE_UP to restrict lower-integrity processes from opening a higher-integrity process for either read or write access.
The lower-integrity process has only generic execute access. Generic execute access includes the following:
- SYNCHRONIZE, PROCESS_QUERY_LIMITED_INFORMATION
Generic read access to a higher integrity process (PROCESS_VM_READ access to the virtual memory of a process, and PROCESS_QUERY_INFORMATION) is restricted to block the ability of lower-privilege processes from gaining read access to memory that may contain password data or other key material that is used for authentication. Generic write access to the higher-integrity process is blocked by the NO_WRITE_UP policy. The generic write process access rights include:
Current user registry hive
Most of the objects in the user profile are not assigned an explicit mandatory label and therefore have an implicit default integrity level of medium. This applies to the HKEY_CURRENT_USER (HKCU) hive of the registry. Keys that are created under HKCU have an implicit medium integrity level. That means that, for users who are members of the Administrators group, the HKCU hive is writeable by applications running with either a medium-integrity standard user access token, or the high-integrity full administrator access token. This must be the case for application compatibility reasons. Recall that the HKEY_LOCAL_MACHINE (HKLM) hive has a default security policy that grants Administrators and System full control, and users read and execute access. The HKLM hive is modifiable only by elevated processes that are assigned the full administrator access token. The HKLM hive is not protected by a high mandatory label.
Since the default integrity level for objects that do not have an explicit mandatory label is medium, it is clear that users who are members of the administrators group may run programs at different privilege levels (medium and high) that share HKCU and user profile data. Windows Vista does not enforce a strict boundary between medium-integrity and high-integrity processes. The high-integrity process is allowed to “read down”. It is common for applications running with a full-privilege, high-integrity access token to read configuration information from HKCU or to accept input files that affect the behavior of the high-integrity process. Applications that run with full privilege should use HKLM to store configuration information that is modifiable only by administrators. Full privilege applications also need to verify that user input data is well formed before processing user modifiable files.
COM is integrity aware
COM is the framework for building application components and object services. The COM infrastructure is aware of the integrity level of a client calling CoCreateInstance and the server process running a class instance. The areas of COM functionality where integrity levels influence behavior are:
- COM elevation moniker allows clients to launch elevated services at a high integrity level after the administrator provides consent, or a standard user provides explicit administrator credentials.
- Server classes that run elevated above the medium integrity level must have the CLSID defined in HKLM registry hive.
- COM prevents clients at a lower integrity level from binding to running instances of servers at a higher integrity level, unless the server programmatically allows access from lower clients.
The COM elevation moniker allows applications at a low or medium integrity level to launch COM services in a process running with elevated rights at high integrity. The elevation moniker allows specific tasks that are designed to run elevated and not intended for complete application compatibility. COM elevation is integrated with UAC elevation. The elevated COM server process is assigned a full-privilege, elevated-access token with high integrity. COM does not allow clients at a lower level to bind to a running instance of the server at a higher integrity level.
If a COM server is designed to support connections from lower-integrity clients, the server can programmatically modify the launch/activation permissions in the registry for the CLSID to allow binding from a lower-integrity client. COM uses the NO_EXECUTE_UP mandatory policy in a mandatory label ACE to control whether clients are allowed to bind to a server instance at higher integrity level. The COM launch/activation access permissions are mapped to generic execute access rights in the GENERIC_MAPPING used by COM for checking activation. The integrity level in a mandatory label associated with the object identifies the lowest integrity level of a client that is allowed to bind to the server. Similar to file system access, the default implicit mandatory policy allows medium-integrity clients to bind to servers.
For COM servers that are designed to allow a low-integrity client to bind to an instance of the server, the COM activation permissions are set by the server code.
To allow a low-integrity client to bind to the server
Define a mandatory label with a NO_EXECUTE_UP (NX) policy for low integrity level. The SDDL for the object security descriptor with the mandatory label policy for low integrity is the following:
Convert the string security descriptor to a binary security descriptor.
Set the Launch Permissions for the CLSID for the server CLSID using the binary security descriptor.
The COM security UI, dcomcfg.exe, does not support integrity levels.
Code examples for how to set COM launch permission mandatory policy are available in Windows Integrity Mechanism Resources for more information on COM and integrity level support.
Services are assigned the system integrity level
The Service Control Manager (SCM) starts service processes using a special service account or a username and password. The special service accounts are LocalSystem, LocalService, and NetworkService. Services running under one of these service accounts have special privileges, such as the SE_IMPERSONATE_NAME privilege that allows the service to take actions while impersonating other users. Windows Vista assigns a system integrity level to the process object for services running under one of the special service accounts. The following image of Process Explorer shows the system integrity level assigned to the access token for special service accounts.
Figure 6 System integrity level for services
Although the service process has a system integrity level, the securable objects created by these subjects are not assigned a system mandatory label. The objects created by services (except child processes, threads, access tokens, and jobs) have an implicit medium integrity level.
The service changes for Windows Vista describe changes to services to improve security, reliability, and manageability. The changes for services improve system security by isolating services in Session 0, and by isolating the resources that services can access using service SIDs. The system integrity level for special service accounts is consistent with the service isolation objectives. Service processes running at the system integrity level are protected from access a by lower-integrity process. The process access rights that are available to lower-integrity processes to open a service process are limited to the following:
Some applications are designed using multiple cooperative processes that may be running in one or more service accounts. Most interprocess communication (IPC) mechanisms between processes and services, such as RPC, are not restricted by integrity level. Services need to be particularly careful to validate input from low-integrity clients.
Duplicate handles between services
Service applications using multiple processes are sometimes designed to duplicate handles to objects, such as files, between server processes. If all the processes are running under the same special service account, the default security on service processes does not introduce restrictions. The default DACL on service processes running under special service accounts does not grant PROCESS_DUP_HANDLE access, which is required for DuplicateHandle calls. Application service designers have to implement functionality to grant PROCESS_DUP_HANDLE access on the service process object to another user account used by a co-process in order to share handles between application processes that run under different user accounts. But if the service into which you want to duplicate the handle is a special service account running at a system integrity level, a co-process running at a high or medium integrity level will not be able to obtain PROCESS_DUP_HANDLE because of the mandatory label policy. Even if the DACL grants PROCESS_DUP_HANDLE access, the mandatory label policy does not allow lower-integrity callers that access. If this situation affects the service application design, the application service code will need to change so that the process that initiates DuplicateHandle is at an integrity level higher than the integrity level of the process that is the source of the handle. That is, a higher-integrity service can duplicate a handle into its own process as a target from a lower-integrity process as the handle source.
The SE_IMPERSONATE_NAME privilege allows a server process to impersonate the security context of a client process. The Impersonate privilege is a powerful privilege. The integrity mechanism associates the impersonate privilege with access tokens that have a high or system integrity level. The integrity mechanism enforces the policy that a subject can impersonate a client at a higher integrity level, only if it has the Impersonate privilege.
A scenario where this policy restriction applies would be when a low-integrity process spoofs UI to persuade an administrator user to enter administrator credentials. The malicious code uses the credentials to call LsaLogonUser and ImpersonateLoggedOnUser to attempt to launch a process at a higher privilege level. The integrity mechanism policy for impersonation access tokens is that the integrity level of the access token that is returned by LsaLogonUser must be no higher than the integrity level of the calling process.
Root folder at high integrity level
The root folder of the system partition, typically C:\ has historically been used as a convenient place to store programs or temporary files, although the practice is not encouraged. Setup programs that require administrator privileges are often copied to the root folder before being launched. The default security policy for the root folder is designed to allow authenticated users to create subfolders under the root folder, but allow only administrators to create files in the root folder. Furthermore, ideally the policy does not allow non-administrative users to modify files in the folder that have been created by administrators. This policy is difficult to define using only the ACL for the root folder.
By setting a mandatory label with a high integrity level that applies to child objects, but not to child containers, the default security for the root folder meets this policy. Standard users that run programs at the medium integrity level cannot modify files created by administrators in the root folder, even if the ACL grants users modify access. The root folder has an inheritable mandatory label at high integrity that is object inherit and that does not propagate to subfolders.
The following image shows the default security settings on the C:\ root folder, including the object inherit mandatory label at high integrity. Table 9 shows the definitions for the abbreviations in the image.
Table 9 Image abbreviations
No write up
Figure 7 Mandatory label on the root folder
Protected Mode Internet Explorer at low integrity
Internet Explorer is an example of an application that is designed to accept arbitrary data and extensible code from the Internet. Because the source of Internet content is rarely authenticated (signed), we have to assume that all input from the Internet is untrustworthy. Attacks against Internet Explorer, or against any other Internet browser, demonstrate the untrustworthy nature of dynamic content and data available from the Internet. From the security perspective, we assume that the Internet Explorer process itself is compromised and untrusted, and we look for solutions that limit the potential damage done by attacks on the browser. Some proposed solutions to browser-based attacks try to isolate the Web browser completely from other applications and data. Unfortunately, complete isolation of the browser has significant impact on the user’s browsing experience, such as the ability to start programs automatically to read various file types, like .pdf files. Complete isolation hampers common user experiences such as uploading pictures to Web sites, if the browser does not have read access to user data files.
The goal of Protected Mode Internet Explorer is to reduce the access rights available to the process, in order to limit the ability of an exploit running in the browser to create unwanted startup files, modify user data files, make annoying changes to browser configuration settings, or drive the behavior of other programs running on the desktop. All code running in Protected Mode Internet Explorer in a low-integrity process is considered untrustworthy. The default medium integrity level for objects prevents the browser from opening any directories, files, or registry keys for write access, except those that are explicitly labeled at low integrity. UIPI prevents the low-integrity browser code from sending any potentially damaging window messages to other applications that are running on the desktop.
The browser that is running at low integrity does have read access to user data files. Because the Windows integrity mechanism does not enforce confidentiality, it does not restrict the flow of information. The process can also use default credentials to initiate network connections, such as to a network proxy server (necessary when authentication is required to connect to the Internet), or to a network printer device to print a web page. The low-integrity process can also initiate an authenticated connection to other network services and thereby authenticate to those servers as the current user.
The application design of Internet Explorer needed some restructuring to run under Protected Mode at a low integrity level. The primary change is that certain program operations were moved out into a separate process, known as a broker process, running at a medium integrity level. The broker process is started at medium integrity level when the user clicks on the Internet Explorer icon or on a URL link. The broker checks the URL and zone policy and launches a child process, iexplore.exe, at the low integrity level to make the Internet connection and render the web page. The following image from Process Explorer shows the ieuser.exe, broker process at medium integrity level, and the iexplore.exe process at low integrity level.
Figure 8 Protected Mode Internet Explorer processes
Everything the user experiences in the Internet Explorer Web browser is done inside the low integrity process. A few specific operations, such as changing Internet Options settings, or the Save as file dialog, are handled by the broker process. If the URL is a trusted site, based on the default zone policy settings, the broker process starts a different instance of iexplore.exe in a medium-integrity process. All browser extensions and ActiveX controls run inside the low-integrity process. This has the advantage that any potential exploit to a browser extension is also running at low integrity.
Internet Explorer is somewhat more complicated than other applications because it hosts browser extensions and ActiveX controls that are not developed by Microsoft, it launches other applications based on mime types for different file extensions, and it integrates the client window from different applications within a single parent window frame. Users also download software from the Internet through the browser and immediately launch an application package or application installer. Many of these operations require help from the broker process at a higher integrity level to mediate through the user to confirm an operation. Otherwise, code running in the browser could install malicious software on the system and try to modify or delete the user’s data. Installation of ActiveX controls is performed using an elevated task started by UAC that requires administrator rights.
Because Internet Explorer supports a wide range of user interactions between the browser and other local applications (copy and paste is one obvious example), the integrity mechanism that limits write access to objects is not a complete isolation mechanism. The design of Protected Mode Internet Explorer looked at many different interactions and specifically tailored the behavior of the broker and low-rights iexplore.exe process to maintain least-privilege functionality while providing a rich, highly collaborative user experience.
For more information about Protected Mode Internet Explorer, see Understanding and Working in Protected Mode Internet Explorer (http://go.microsoft.com/fwlink/?LinkId=90931).