Learn To Be Least

An administrator accidentally downloads malicious code while surfing the Web. A Windows developer writes code that requires Administrator privileges to work properly. These dangerous practices violate one of security's most fundamental concepts: the principle of least privilege. This principle states that you should give a user or a piece of code only the privileges it needs to do the job--nothing less, and certainly nothing more. Malicious code can do much more harm when it can execute in the security context of a highly privileged account, and highly privileged processes can do much more harm when compromised (or simply buggy).

Least privilege has long been a well-respected and supported principle in the UNIX world, but Microsoft started taking it seriously only with the release of Windows XP and Windows 2000. Support for the Least-Privileged User Account (LUA) is a key security theme of Microsoft Vista (formerly code-named Longhorn), but for now, XP and Win2K provide several tools that you can use to honor least privilege. Use these tools to run Windows processes and applications from an LUA or non-administrator account--and put security first.

Fast User Switching
Fast User Switching is an XP Professional Edition (and XP Home Edition) feature that lets multiple, simultaneous interactive logon sessions take place on a Windows computer. Fast User Switching lets users easily switch between logon sessions without logging off or closing running applications. The feature is available only on machines that have at least 64MB of RAM, are members of a workgroup (not domain-joined machines), have the Welcome logon screen enabled, and don't have a Graphical Identification and Authentication (GINA) Module replacement (e.g., a custom GINA that enables biometric authentication or another strong authentication method) installed. Furthermore, the user mustn't have enabled Offline Files support.

To enable Fast User Switching for users, open the Control Panel User Accounts applet, then click Change the way users log on or off. From the Select logon and logoff options dialog box, which Figure 1 shows, you can enable the Welcome screen (if it isn't already enabled) as well as enable Fast User Switching. (I explain the advantages and disadvantages of using the Welcome screen in "A Matter of Trust," July 2005, InstantDoc ID 46591.)

Users can open another logon session by clicking Start, Log off, then selecting the Switch User option; by opening Task Manager (by pressing Ctrl+Alt+Del), then selecting Switch User from the Shut Down menu; or by holding down the Windows key and pressing the L key. To see which user sessions are active on your computer, open Task Manager and go to the Users tab. (When you have Administrator privileges, you can also use this screen to log users off, disconnect users, or send users a message.)

To use Fast User Switching to better honor least privilege, create an account that has computer administrator privileges. You can assign this account a password or leave it with a blank password. (In XP and later, accounts with a blank password are more secure than accounts that have an assigned password; by default, blank password accounts aren't allowed to log on remotely to a system. You can control that feature by using the Accounts: Limit local account use of blank passwords to console logon only Group Policy Object--GPO.)

Next, create a user account that has limited privileges. Again, you can assign a password or leave the password blank.

Use the user account for day-to-day work such as surfing the Web, email, and Instant Messaging (IM). Switch to the security context of the administrator account when you need to install programs or run programs that require Administrator privileges. (For an overview of programs that truly require Administrator privileges, see the Microsoft article "Certain Programs Do Not Work Correctly If You Log On Using a Limited User Account," at http://support.microsoft.com/?kbid=307091, or visit the nonadmin Wiki at http://nonadmin.editme.com/knownproblems.) When you finish such jobs, log off the administrator account and switch back to the user account. Because this account has reduced privileges, you don't necessarily need to log off the user account each time you leave your computer. Simply locking the screen is usually sufficient.

Before you implement Fast User Switching, be aware that the feature's improper use can create security risks. Don't leave an administrator logon session running on your system. If your enterprise demands ultra-high security, disable Fast User Switching. At the very least, clearly instruct users always to log off administrator sessions when they've completed work that requires Administrator privileges. To disable Fast User Switching, you must disable the use of the Welcome screen to enforce the use of secure logon (Ctrl+Alt+Del). There are several methods for doing so on a standalone XP system:

RunAs
The RunAs command-line utility (runas.exe) is the easiest way to switch to the security context of another user when you're using a domain-joined machine. (On a standalone machine, use Fast User Switching.) RunAs is rooted on the Secondary Logon service, which lets you start logon sessions that use other credentials within the current logon session. (Before Win2K, the Microsoft Windows NT Server 4.0 Resource Kit su.exe utility provided this functionality.) The Secondary Logon service is installed by default in Win2K and later systems and starts automatically when the system boots.

For example, to start the Microsoft Management Console (MMC) in an administrator security context, you can type the following RunAs command at the command line:

runas /user:administrator mmc

RunAs then prompts you to enter the administrator's password, as Figure 2 shows. If the password is correct, the utility will start an instance of the MMC. Table 1, page 8, gives an overview of the most important RunAs command-line switches.

You can also run RunAs from Windows Explorer. To do so, right-click an executable's or shortcut's icon and select Run as to open the Run As dialog box, which Figure 3, page 8, shows. This dialog box presents options to select alternate credentials. For icons that don't offer the Run as option in the regular context menu (e.g., Control Panel applets), hold down the Shift key while right-clicking the icon. Or, you can make RunAs the default action for a particular executable or shortcut by opening that executable's or shortcut's Properties, clicking Advanced, and selecting the Run with different credentials check box.

Another good practice is to create a shortcut to an Administrator command-line window on the desktop of your user account, then configure the window's appearance so as to draw your attention to the fact that whatever you do in that window is running in a highly privileged environment. For example, you can change the shortcut's target configuration in the shortcut's Properties by pointing the Start in field to the C:windowssystem32 directory, then entering the following command in the Target field:

runas.exe /u:Administrator "%windir%System32cmd.exe /k cd c: && color fc && title !!!!! Administrator console!!!!!"

Take another look at Figure 3. Notice that the Run As dialog box also includes an option to select the Current user; when you select that option, you can also select the Protect my computer and data from unauthorized program activity check box. These options start the selected application in the security context of the current user account, but with a restricted access token--meaning that the new process will be denied several privileges:

These restrictions make this advanced RunAs option a powerful security feature--handy, for example, when you want to block certain Web sites from writing data to your local system. More information about this option is available from well-known Windows least-privilege guru Aaron Margosis's blog (http://blogs.msdn.com/aaron_margosis/archive/2004/09/10/227727.aspx).

You can also use RunAs to start the complete Windows shell in an alternate security context. This capability can be useful when you want to use drive mappings in your secondary logon session. A drive that is mapped from the command line in a secondary logon session won't be accessible from your Windows Explorer session unless you start the complete Windows shell in the alternate security context. To do so, kill the explorer.exe process from Task Manager. Then, using Task Manager's File, Run menu option, type

runas /u:joe explorer.exe

You can nest multiple RunAs commands. Suppose you want to install software on your machine, and the software image is on a network drive. Access to the network drive typically requires a different set of local or domain credentials. You can nest RunAs commands as follows:

runas /u:%COMPUTERNAME%Administrator "runas /netonly /u:%USERDOMAIN%%USERNAME% cmd.exe"

This command will prompt you for credentials twice: first for your local Administrator credentials, second for your domain credentials. The result will be a command window that runs in the security context of the local Administrator account (this means you also use the local Administrator's profile) but uses your domain credentials to access the remote resources.

One thing to keep in mind is that RunAs can trip up when being used to start Windows Explorer. See the sidebar "RunAs Gotcha" for an explanation.

DropMyRights
Michael Howard's DropMyRights program can be used to launch a new process in the context of a non-administrator account with reduced privileges. This program takes the user's current security token, removes various privileges and SIDs from the token, then uses the token to start a new process. For example, to run Microsoft Internet Explorer (IE) in the context of a non-administrator account, use the following command:

dropmyrights iexplore.exe

DropMyRights supports three non-administrator accounts: Normal user (the default), Constrained user, and Untrusted user. You specify which account you want to use by appending an N, C, or U to the DropMyRights command. Each account's privileges are described in detail in the Microsoft article "Browsing the Web and Reading E-mail Safely as an Administrator" (http://msdn.microsoft.com/library/en-us/dncode/html/secure11152004.asp); you can also download DropMyRights at that URL.

Privilege Bar

The Privilege Bar, which Figure 4 shows, is a Windows Explorer and IE add-on toolbar developed by Aaron Margosis. The Privilege Bar shows the privilege level of the current Windows Explorer or IE window. The circle on the bar will be red for members of the Administrators group, yellow for Power User members, and green in all other contexts. When you click the circle, the Privilege Bar pops up a window that displays detailed group and privilege information (basically, the content of the access token) for the current logon account.

Even though this tool doesn't offer functionality to switch to the context of an LUA account, it can help keep users aware of the dangers of surfing the Web and browsing local and network resources when using highly privileged accounts. You can download the Privilege Bar code, which you must install manually, and related instructions from Margosis's blog (http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/195350.aspx).

Least Is the Greatest
There are many straightforward solutions to help you--and users--honor the principle of least privilege. The techniques I've discussed here represent only a few. Other solutions include using virtualization software (e.g., VMware, Microsoft Virtual PC) to isolate security contexts and restricting what can run on user desktops (e.g., by using Microsoft Software Restriction Policies). And of course, user education and training is paramount. To learn more about putting least privilege into practice, read "Get the Most from Least Privilege," September 2005, InstantDoc ID 47176.

Instructs RunAs to use logon credentials previously saved by the user (in the credential manager). The user won't be prompted for the password of the alternate user specified in the RunAs command.