Windows Vista UAC – Further Reading

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.

7 thoughts on “Windows Vista UAC – Further Reading

  1. Jun Meng

    Good article!

    But I am still confused about how Vista knows which parts should be protected. Are those protected parts still BIOS, booting area, c:Windows, c:Program files, etc like in Windows XP/2003?

    If so, normal Windows XP/2003 user can install most of software on D: drive without bothering helpdesk, which should be safe because virus/spyware cares about system files on C:.

    If a software must be installed on C:, Administrator account should be used. But how can Administrator knows it is safe or not? If Administrator assume the software is safe (which is the case for most home users), Vista can not stop the virus/spyware being installed, right?

  2. robgarrett

    Hi Jun,
    Good question – what Vista determines as a protected is down to the resource in question – typically, any of the file system pertaining to the operating system, applications, registry etc. In addition to those in XP/2003, Vista now limits the user from accessing many more WIN32 API calls than before.
    Since Vista now has a way to elevate privileges when there is a specific task to perform, Vista can provide standard token users with access to more configuration options than before. E.g., the date/time property sheet was inaccessible to LUA users under XP/2003 – somewhat annoying if you liked using the control as a quick view calendar, in Vista users can see the settings but need to elevate only if they wish to change the system date/time.
    The question of whether some third-party is safe to install or not is determined by the source of the software (IMHO) – if you purchased the software from MS or reputable source then safe bet is that the software is non malicious, however, if you downloaded it from a hacky website then chances are that the application will contain spyware.
    The purpose of UAC is not to prevent administrators from making the moral decision to install certain software applications or for enterprise administrators to prevent users from installing apps on their local PC (although it helps with this). UAC is there to protect the user from installation of software without their knowledge. Since many users feel the need to run with administrator privileges, UAC provides them with a safety net, knowing that any application that wants to attack the registry, app/OS file-system, boot system etc, has to gain approval first. Of course, there is nothing stopping an administrator from just clicking the OK button, but then they cannot say they did not know.
    Users who are used to running XP/2003 in LUA will not see much difference in Vista – applications that require administrative access to execute did not run in XP/LUA and more than they will run in Vista. Those running as administrators, especially users who like to install non-XP compatible tools and utilities (most large-scale applications like Adobe and MS products are XP/Vista compatible) will find that they see prompt for elevation a lot (there is nothing stopping them disabling UAC, but that defeats the point).
    UAC has shifted the responsibility of security from the ordinary user’s lap to the developer. Application developers now have to pay special attention to UAC to guarantee that their application will execute on default Vista installations – e.g., careful use of administrative calls, and placement of data files. Normal users (like my Mom) who want to surf the Internet and read email without concerning themselves with malicious applications installing from the web can now do so because UAC has their back.
    Perhaps, now, I shall hear less about peers (non-techies) who have converted to MAC because they are overwhelmed with spyware and viruses.
    BTW, installing an application on D without administrator privileges is as good as installing the application in the user’s default user area – the application cannot write to HKEY_LOCAL_MACHINE, register services, or install shortcuts for other users etc – it is as good as sandboxed and can only change the current user’s profile. The operating system and other applications remain protected.

  3. http://

    Hi,

    I tried including the .manifest file for my application exe and but still UAC prompts are poping up on launching shortcuts.

    Kindly guide if something else needs to be done for this.

    Thanks,
    nethra

  4. robgarrett

    Nethra,

    Including an .manifest file will not prevent the elevation popup if your code needs to perform a platform secured operation. The manifest definition just tells Vista whether you need elevation to execute the application from the start or on demand.

    R.

  5. http://

    I’m using VS 2008 and everytime I try to include the <requestedExecutionLevel level=”requireAdministrator” uiAccess=”false” /> into the manifest the compiler responds with “ClickOnce does not support the requested execution level “requireAdministrator””. The same for highestAvailable. Any ideas?

Comments are closed.