Chapter 2: User Account Control, Tokens, and Integrity Levels

Overview

Windows Vista offers a new set of technologies and defenses that focus on user accounts and on protecting users from malicious software. One of the earliest design decisions made in Windows Vista was to make it easier for administrators to control their users’ desktops by setting them up as “ordinary users” rather than administrators. When a user runs as an administrator, that user can perform virtually any function, good or bad, on the computer. Security issues aside for a moment, running as an administrator reduces the reliability of the system dramatically, and increases support costs because users-as-admins can install any software they want, load and unload drivers, and so on.

Versions of Windows prior to Windows Vista supported standard users, but many common tasks simply failed unless the user ran as a full-privilege administrator. In fact, many common applications simply failed if the applications were not run by an administrator because the developers did not anticipate users running as standard users in the first place. Mainly because the older Windows versions (such as the now-unsupported Windows 95 and Windows 98) had no concept of access control and authorization, so all users were administrators. Hence, code written for Windows 95, Windows 98, and Windows Me could scribble all over the operating system. But on the operating systems based on Windows NT, Windows 2000, Windows XP, and later, there are access control mechanisms in place, and code can’t write to any place it wishes–unless the user is an administrator. Probably the most common mistake made by application developers is to write user data to protected portions of the file system and registry, such as the Windows and Program Files directories and the HKLM portion of the registry. Only administrators and sometimes Power Users can write to these locations, and software that writes to these locations will operate correctly only if it’s run by high-privilege users. By default, user accounts in Windows XP are administrators, and because it is the default, software developers assumed this default configuration and built their software accordingly. While the default for Windows 2000 for a newly created user was a standard user, Windows 2000 was typically used in a business setting. When Windows XP is joined to a domain, the default domain user has only limited user rights, and new standard users are added to the Power Users group for application compatibility.

Important  

The Power Users group is deprecated in Windows Vista because it is so powerful; the group is still in the operating system, but no account is in the group, and no Access Control Lists (ACLs) are left that reference Power User.

Windows Vista changes all the rules. Users are unprivileged users (often referred to as standard users); by default, administrators are unprivileged users as well. The reason Microsoft enabled standard users to fully use Windows was to reduce the potential threat to the system if the user or administrator ran malicious software. When code, malicious or not, runs with full administrative privileges, it is not constrained to portions of the operating system–it can manipulate any part of the operating system. User Account Control (UAC) enables most applications to run properly without administrative privileges and provides users with a clear indication when they launch an action that requires full administrator privileges.

The goal of this chapter is to explain how you can write applications that work correctly and take advantage of the new user account-related features in Windows Vista. In this chapter we discuss the following topics:

• User account control in depth

• User interface considerations

• Virtualization

• Integrity levels

• Debugging application compatibility issues in Windows Vista

• Privileges new to Windows Vista

This chapter is code-dense, and the reader is urged to refer to the complete code samples included in the Ch02 folder of the sample code. Let’s get started.