Basics

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. See the references in Appendix B for further useful sources of information.

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.

IMPERSONATION VERSUS DELEGATION

The difference between impersonation and delegation is not well understood in many circles. Impersonation, as we mentioned, allows a process to act on behalf of a user to access resources local to the remote system on that user's behalf. Normally the user is a client of the process, and the process provides some service on behalf of the user. For example, when a user accesses a shared resource on a server, the server service on that server can request an impersonation token for the user. The server service can then launch a separate thread using that impersonation token and attempt to access the requested resource. The access check against the resource (see Chapter 5 for more details on access checks) will take place against the impersonation token of the client, not against the process token of the server service. This allows for very simple and efficient access control.

Impersonation tokens are restricted such that they are valid only on the system they were issued on. This helps contain attacks. To see how, assume a malicious user replaces the server service with a fake service and then entices a user to connect to it. The fake server service now receives an impersonation token for the user, but it can only be used to access local resources on the system the attacker already controls. In other words, it gives the attacker no extra access beyond what he had before.

In order to allow processes to request access to network resources on behalf of users delegation is used. Delegation is the impersonation of clients over the network. If a server is trusted for delegation it can create tokens which can be used in network requests to access remote resources. This makes delegation a very sensitive operation and trusting something for delegation essentially means making it as sensitive and powerful as any domain controller. A subject that is trusted for unconstrained delegation can perform any task in the domain on behalf of any user in the domain. In Windows Server 2003 constrained delegation, which restricts the actions the trusted subject can take, was introduced specifically to allow more control over this sensitive area. To learn more about impersonation and delegation, refer to the Windows Software Development Kit.