Comparison of privilege authorization features

A number of computer operating systems employ security features to help prevent malicious software from gaining sufficient privileges to compromise the computer system. Operating systems lacking such features, such as DOS, Windows implementations prior to Windows NT (and its descendants), CP/M-80, and all Mac operating systems prior to Mac OS X, had only one category of user who was allowed to do anything. With separate execution contexts it is possible for multiple users to store private files, for multiple users to use a computer at the same time, to protect the system against malicious users, and to protect the system against malicious programs. The first multi-user secure system was Multics, which began development in the 1960s; it wasn't until UNIX, BSD, Linux, and NT in the late 80s and early 90s that multi-tasking security contexts were brought to x86 consumer machines.
Security considerations.
Falsified/intercepted user input.
A major security consideration is the ability of malicious applications to simulate keystrokes or mouse clicks, thus tricking or spoofing the security feature into granting malicious applications higher privileges.
Fake authentication dialogs.
Another security consideration is the ability of malicious software to spoof dialogs that look like legitimate security confirmation requests. If the user were to input credentials into a fake dialog, thinking the dialog was legitimate, the malicious software would then know the user's password. If the Secure Desktop or similar feature were disabled, the malicious software could use that password to gain higher privileges.
Usability considerations.
Another consideration that has gone into these implementations is usability.
Identifying when administrative rights are needed.
In order for an operating system to know when to prompt the user for authorization, an application or action needs to identify itself as requiring elevated privileges. While it is technically possible for the user to be prompted at the exact moment that an operation requiring such privileges is executed, it is often not ideal to ask for privileges partway through completing a task. If the user were unable to provide proper credentials, the work done before requiring administrator privileges would have to be undone because the task could not be seen though to the end.
In the case of user interfaces such as the Control Panel in Microsoft Windows, and the Preferences panels in Mac OS X, the exact privilege requirements are hard-coded into the system so that the user is presented with an authorization dialog at an appropriate time (for example, before displaying information that only administrators should see). Different operating systems offer distinct methods for applications to identify their security requirements:
 pete ALL = /usr/bin/passwd [A-z]*, !/usr/bin/passwd root
<security>
 <requestedPrivileges>
 <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
 </requestedPrivileges>
</security>