UAC is part of a long-term strategy to change the way application developers write code and the way we as end users use the software they write. The idea is to reduce the inherent exposure in having the majority of Windows users running as an administrator all of the time. Unix has long had a toolset and basic architecture designed around the idea of least-privilege. Windows has an architecture that supports using the least possible privilege to perform the task at hand, but that is unfortunately not how the system has been used. First, there is a huge legacy of applications that were written under the Windows 3.
x and 9
x model that everyone was an administrator. To use those applications, virtually all developers ran as administrators, and consequently, the code they wrote was never designed to run with least privilege. Microsoft's own developers did this too, which meant that very little of the operating system or other applications were really designed to take advantage of the least privilege model.
By the time Microsoft started actually thinking seriously about helping end users run as non-administrators, it became very obvious, very quickly, that their ability to do so was virtually non-existent for the vast majority. The "Run As …" command was introduced in Windows 2000 to allow a user to elevate a task without having to log off and back on again. However, it was so inadequate to the task that it went almost entirely unused, save for a few brave and honorable people who wrote scripts to make it more usable. To fix this problem required a fundamental architecture change. UAC is where this architecture change was first delivered. In a way, it is version 1 of Microsoft's effort to enable people to run with least privilege. One of its primary goals is to mitigate poorly written applications so that more people can run as standard users, thereby forcing ISVs to write more applications that run as standard user. If people turn off UAC, this goal will never be met.
In order to enable UAC a number of fundamental structures in the OS needed modification. We will begin our exploration of UAC with those structures.
Security Identifiers
Most people that use a Windows NT-based operating system (OS), including Windows 2000, Windows XP, Windows Server 2003, and Windows Vista, are aware that users are associated with user names in the operating system. Under the hood, however, the user name is not the actual item identifying a user. Under the hood the operating system uses a Security Identifier (SID). A SID is a globally unique numeric value that identifies a user, a subject in computer security parlance, in the system. Subjects include not just users but also groups, computers, domains, and, in Windows Vista, even some processes. The SID is composed of an authority that issues the SID, a set of one or more sub-authorities, and finally, a relative identifier. In text form, a SID may look as follows:
S-1-5-21-57989841-1336601894-682003330-500
Everything in this SID up to the last part (–500) is the SID for the computer or the domain itself. The last part makes this a SID of a user. Analyzing the pieces separately, we start with S, which stands for SID. 1 is the revision level, or version number of the SID format.
5 is the identifier authority that issued the SID. 5 is the numeric representation of SECURITY_NT_AUTHORITY, or the Windows NT operating system (remember that Windows Vista is just the trade-name for the latest in a line of Windows NT-based operating systems, which explains why it is Windows version 6.0.6000 internally).
21 is the first sub-authority, which stands for SECURITY_NT_NON_ UNIQUE, and means that this SID may not be universally unique. There may be other computers out there that have exactly the same SID as this one.
The next three blocks are sub-authorities that identify the computer. You may see varying numbers of these sub-authorities, particularly on SIDs issued from domains.
Finally, we have the Relative Identifier (RID). A RID of 500 always identifies the BUILTIN\Administrator account, which exists on all Windows computers. A RID of 501 indicates the built-in guest account. The actual RIDs for users you create typically start at 1000 or 1100, depending on the exact operating system you are using. RIDs are incremented each time you add a user. Even if a user is deleted the RID is never reused on the same system. This is why you get the warning that each user is identified with a unique identifier when you try to delete a user account. Creating a new user with the same name as a deleted one still makes it a different user as far as the operating system is concerned because it has a different SID.
SIDs are used in many situations beyond those that are within the scope of this book. There are entire books that address the topic.
Security Token
When a subject logs on the OS constructs a security token, sometimes called an access token, for the subject. The token contains essential information about the subject. In addition to the subject's own SID the token also contains all the SIDs of all the groups the subject is a member of, along with a list of all the privileges and rights the subject has been granted. In Windows Vista, you can view the complete contents of your token with the whoami command.
Microsoft Windows [Version 6.0.6000]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Users\Jesper>whoami /fo list /all
USER INFORMATION
----------------
User Name: jj-vistartmtst\jesper
SID: S-1-5-21-604828993-3653798594-2491376708-1000
GROUP INFORMATION
-----------------
Group Name: Everyone
Type: Well-known group
SID: S-1-1-0
Attributes: Mandatory group, Enabled by default, Enabled group
Group Name: BUILTIN\Administrators
Type: Alias
SID: S-1-5-32-544
Attributes: Group used for deny only
Group Name: BUILTIN\Users
Type: Alias
SID: S-1-5-32-545
Attributes: Mandatory group, Enabled by default, Enabled group
Group Name: NT AUTHORITY\INTERACTIVE
Type: Well-known group
SID: S-1-5-4
Attributes: Mandatory group, Enabled by default, Enabled group
Group Name: NT AUTHORITY\Authenticated Users
Type: Well-known group
SID: S-1-5-11
Attributes: Mandatory group, Enabled by default, Enabled group
Group Name: NT AUTHORITY\This Organization
Type: Well-known group
SID: S-1-5-15
Attributes: Mandatory group, Enabled by default, Enabled group
Group Name: LOCAL
Type: Well-known group
SID: S-1-2-0
Attributes: Mandatory group, Enabled by default, Enabled group
Group Name: NT AUTHORITY\NTLM Authentication
Type: Well-known group
SID: S-1-5-64-10
Attributes: Mandatory group, Enabled by default, Enabled group
Group Name: Mandatory Label\Medium Mandatory Level
Type: Unknown SID type
SID: S-1-16-8192
Attributes: Mandatory group, Enabled by default, Enabled group
PRIVILEGES INFORMATION
----------------------
Privilege Name: SeShutdownPrivilege
Description: Shut down the system
State: Disabled
Privilege Name: SeChangeNotifyPrivilege
Description: Bypass traverse checking
State: Enabled
Privilege Name: SeUndockPrivilege
Description: Remove computer from docking station
State: Disabled
Privilege Name: SeIncreaseWorkingSetPrivilege
Description: Increase a process working set
State: Disabled
Privilege Name: SeTimeZonePrivilege
Description: Change the time zone
State: Disabled
Every process that runs on the user's behalf gets a copy of the token. This process token, as it is referred to when it is attached to a process, contains much of the same information as the security token. It will also have additional information related to how it may be used, and whether it has some things removed. A process the user runs directly receives a primary token. By contrast, a process run on the user's behalf by something else, such as when a computer is performing some task on behalf of a remote user, gets an impersonation token. An impersonation token is essentially used by a process to "spoof" the subject. See the sidebar "Impersonation versus Delegation" for more information on impersonation.
