In our society, policemen are granted privileges. Think of the lightbar on a squad car and how the world around the policeman changes when he turns it on. People get out of his way, and he can drive through red lights as long as he's cautious. But he doesn't drive around all day with his lightbar on, because he knows that it's safer to drive normally.

A privilege in Windows is a lot like that lightbar. The benefit isn't available to you unless you've been granted the privilege via security policy, as a person can be granted a position on the police force. We generally do our best to hire good people as police, because it's a position of trust that can be abused. A good policeman uses his privilege only when it's appropriate, and he’s very careful when he does. Privileges in Windows are similar: Once you've been granted a privilege, it's listed in your token with a bit that says whether it's enabled or not, and you can enable it to make the operating system behave differently toward you, like turning on the lightbar.

Let's get practical now. When are you ever going to need a privilege? If you want to impersonate a user, you may need the new SeImpersonatePrivilege.¹ If you want to change the time or reboot the system, those are privileged operations (SeSystemtimePrivilege, SeShutdownPrivilege). To see a full list of privileges, open up your local security policy as an administrator and drill down into "User Rights Assignment" (see Figure 21.1). A quick way to get to this console is to type secpol.msc from a command prompt running as an administrator.

Figure 21.1 Privileges are assigned via security policy.

As an exercise, use the whoami tool.² If you type whoami /priv, this program will look at its token and provide a pretty listing of the privileges found there, including whether each privilege is currently enabled or disabled. Try this experiment from a normal user's command prompt (Figure 21.2), then from an admin's command prompt (Figure 21.3). You should see a big difference between the two.

 PRIVILEGES INFORMATION
 ----------------------


 Privilege Name          State   
 ======================= ========
 SeChangeNotifyPrivilege Enabled 
 SeUndockPrivilege       Enabled 

Figure 21.2 whoami /priv output for a normal user

 PRIVILEGES INFORMATION
 ----------------------


 Privilege Name                  State   
 =============================== ========
 SeChangeNotifyPrivilege         Enabled 
 SeSecurityPrivilege             Disabled
 SeBackupPrivilege               Disabled
 SeRestorePrivilege              Disabled
 SeSystemtimePrivilege           Disabled
 SeShutdownPrivilege             Disabled
 SeRemoteShutdownPrivilege       Disabled
 SeTakeOwnershipPrivilege        Disabled
 SeDebugPrivilege                Disabled
 SeSystemEnvironmentPrivilege    Disabled
 SeSystemProfilePrivilege        Disabled
 SeProfileSingleProcessPrivilege Disabled
 SeIncreaseBasePriorityPrivilege Disabled
 SeLoadDriverPrivilege           Disabled
 SeCreatePagefilePrivilege       Disabled
 SeIncreaseQuotaPrivilege        Disabled
 SeUndockPrivilege               Disabled
 SeManageVolumePrivilege         Disabled

Figure 21.3 whoami /priv output for an admin

The normal pattern of usage for a privilege can be demonstrated by an example. Say you want to reboot the system. You know that this is a privileged operation, so you reach up into your process token and try to enable SeShutdownPrivilege. If you've been granted this privilege by policy, your token should have it, and so you'll be permitted to enable it. If you haven’t been granted this privilege, your attempt to enable it will fail, at which point you'll need to deal with the fact that you're not allowed to reboot the system (in a desktop app, you could inform the user of her lack of privilege with a message box, for example). Assuming you've succeeded in enabling the privilege, you'll call the Win32 function ExitWindowsEx to request a reboot. Finally, you should disable the privilege. Notice the pattern here: enable, use, disable—just like the policeman with his lightbar.

Because you're rebooting the system, you might argue that disabling the privilege is a waste of time. But just as you should never get lazy and allocate memory without freeing it, you should never enable a privilege without disabling it as soon as you're done using it. You never know who will cut and paste your code in another project! Besides, how does the routine know that the reboot will actually happen and that your program will actually exit? Often users initiate a reboot only to cancel it when they realize they need to save some work first. It's tough to know all these things deep down in a routine that's responsible for actually implementing the reboot. Make sure each of your security primitives (like privilege usage) follows best practices. Don't take shortcuts.

Some privileges are meant to be enabled all the time if they’re granted. SeChangeNotifyPrivilege (also known as "Bypass Traverse Checking"³) and SeImpersonatePrivilege are notable examples. These are like the policeman's handgun — he’s granted the right to carry it on the street, and he's never on the job without it. If you're granted any of these privileges by policy, the operating system will enable them by default in that first token you get at login time, so you shouldn't need to worry about messing with them at runtime. Many Win32 functions (but not all) incorporate the enabling and disabling of privileges as a convenience. Furthermore, I expect that, as the .NET Framework continues to abstract more of the Win32 API, you'll have less and less need to worry about enabling privileges manually. But this is a technical detail. Security policy will still control who can and cannot perform privileged operations, so you should be aware of the privileges defined by Windows so that you know what requirements your programs will have with respect to security policy.

¹ I say new because this was introduced in Windows Server 2003 and is being actively backported to older systems (it shipped with Windows 2000 SP4, for example, and it's also slated for release in Windows XP SP2).

² This tool shipped with Windows Server 2003, but also comes with the Windows 2000 resource kit. Download it from http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/whoami-o.asp, if necessary.

³ No, this is no typo. The programmatic name is very different from the friendly name, thus ensuring your job security as a Windows programmer.

PortedBy RubenBartelink