Then and Now
Microsoft Windows XP™ initially creates all user accounts as local administrators. Administrators have full access to system-wide resources and can execute any privileged operation. Microsoft guidelines suggest that users run day-to-day tasks under a least privileged account (LUA), however many users prefer to operate at the administrator level for the following typical reasons:
- Home users like administrator rights for similar reasons – applications are installed and available immediately without configuration in separate profile or execution restriction.
- ActiveX controls are glorified COM controls deployable via the Internet and, like COM, require installation. LUA users typically do not receive installation rights, breaking the use of badly designed Active-X controls (controls requiring access to protected areas of the operating system).
- Reduced dependency on helpdesk support – if users can install their own applications there is a reduced burden on the helpdesk and support group because there is no need for centralized deployment mechanisms (SMS, Group Policy) and/or system administrators to install applications manually.
Ensuring that users operate day-to-day tasks as LUA mitigates the impact of malware on critical areas of the operating system and installed applications. However, standard users find they cannot perform typical configuration tasks (change the system time zone or install a printer) without administration rights. Moreover, some applications will not operate on Windows XP without using the “run-as” option or logging on as an administrator, usually involving special permission changes for legacy applications and opening up security vulnerabilities. Windows 95 and 98 had no security model, so legacy applications initially developed for these platforms that have migrated with subsequent versions may not consider security constraints.
UAC - Under the Hood
Windows Vista supports two types of user accounts – standard users and administrator users. Standard users behave much like the LUA user on Windows XP where protected resources on the platform are restricted without prompt for administrator credentials. Unlike the least privileged account-type on Windows XP, standard users can make more configuration changes than before. Only when standard users attempt to change a system-wide resource setting does Vista prompt for administrator credentials. Administrator accounts operate in one of two modes – filtered or elevated. Standard users receive a standard “filtered token,” denoting reduced permissions, upon logon, whereas administrators receive two tokens – the “filtered token” and a “full access token.” During normal operation, administrators use the filtered token, when attempting to execute privileged operations the Application Information Service – a system service facilitating the elevation of user privilege – will elevate the administrator to the higher full trust token.
Application Manifest Files and Elevation
How does Vista know when to elevate? Firstly, to dispel a myth that elevation can occur at any time during the execution of a process – incorrect. The AIS determines required elevations on a per-process basis – and how exactly does it do that?
The Application Information Service makes some assumptions about certain applications – applications labeled “setup.exe,” “update.exe,” and MSI files (plus a few other criteria) are installation applications and AIS requests administrator full access credentials or confirmation. All other application types execute using the filtered token, unless an accompanied manifest file stipulates otherwise.
What is a manifest file?
A manifest file is an XML file associated with an executable application (EXE), containing metadata about the application, and may include trust information for elevation. The following is an example manifest file:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" uiAccess="true"/>
</requestedPrivileges>
</security></trustInfo>
</assembly>
In the above manifest file, the requestedExecutionLevel stipulates the required level and whether elevation is required. Possible levels of execution are:
- asInvoker – The application executes at the same level as the standard user filtered token
- highestAvailable – The application executes at the highest level of privilege the user can obtain
- requireAdministrator – The application requires administrator full access token privilege
.NET EXE assemblies are associated with manifest files when the manifest has the same name as the executable with a “.manifest” extension. For example, the executable test.exe is associated with the manifest file test.exe.manifest. Embedding of the manifest as a resource is also possible.
WIN32 executables also use a manifest to request elevation, although, unlike managed assemblies, WIN32 manifest files must embed in the executable file. The following information details embedding of a WIN32 manifest file:
Link
Default Behavior
The following is the default behavior for Vista installations:
- UAC is enabled by default, so users may experience compatibility prompts with legacy applications
- The first account created during Vista installation is an administrator account (with dual tokens), all subsequent created accounts are standard user accounts
- The built in administrator account is disabled by default
- Elevation prompts are displayed on the secure desktop
The Shield Icon
Common practice is to display a “shield icon” on all controls that require elevation. The following image shows the date and time properties – the standard user can make configuration changes, however, if they press the “Change Date and Time” button AIS will prompt for administrator credentials or consent.
Wait a minute! How can an application prompt for elevation mid-process if AIS determines the execution level before execution?
Answer - Vista provides a clever mechanism called the “COM Elevation Moniker,” which is a mechanism in which applications can execute code in a WIN32 COM server, out of process executable, with elevated execution privileges. Further documentation on developing for Vista UAC provides more in depth detail on the COM Elevation Moniker.