UAC Distilled

As I mentioned in an earlier post (New UAC Whitepaper Released), the UAC team recently published a very detailed whitepaper that covers everything you could every want or need to know about UAC from a developer perspective. I typically begin all my Windows Vista presentations with a discussion of User Account Control (UAC), and I thought I'd share my condensed version of what I've found to be the key high-level points - just in case you haven't yet found the time to read all 91 pages of the whitepaper :-)

I like to think about UAC according to the following three principles:

1. By default, interactive processes launched by the user run as standard user - even if they are a member of the Administrators group.

Let's parse this sentence and look at the key points I want to emphasize:

by default: unless otherwise specified, meaning that some other behavior is possible (see principle #2)

interactive processes: UAC applies to processes running in the interactive session; it does not apply to Windows services that are launched by the SCM (Service Control Manager)

launched by the user: the Windows Vista Shell (the Start menu, the desktop, Explorer, etc.) runs as standard user; applications launched from these locations also run as standard user (unless otherwise specified, as noted above)  

run as standard user: meaning with the kind of minimal default privileges a user has when created

even if they are a member of the Administrators group: under UAC, certain well-defined memberships in security groups (like Administrators) and privileges are stripped from the user's token (this is sometimes referred to as a "filtered token"); from an application's perspective, members of the Administrator's group appear to be plain standard users. (See the section titled Access Token Changes in the UAC whitepaper for a list of the specific groups and privileges that are removed)

2. Privilege elevation cannot occur in process

Privilege elevation is a mechanism by which an application is launched by the OS with the user's full token. (It does not grant any additional privileges that the user doesn't already have.)

There is no API that will enable your code to elevate itself, in-process - you must request the OS to launch a new process that runs elevated (i.e. with the user's full token).

Once a process is running elevated, any process that it creates will also run elevated. (And there's no way to go from a full token back to a filtered token)

3. Privilege elevation requires user consent

Explicit user consent is required in order for the OS to run a process as elevated (i.e. with the user's full token). 

Context is important to the user, when deciding whether or not to give consent.

There are standard visual cues to help define context for the user:

• The security shield icon is used to decorate UI elements that launch privileged operations
• The color of the banner on the elevation consent/credential prompt varies depending on whether the executable is a system app, whether it's signed by a trusted publisher or not signed.