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, 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.
Introduction to implementations
;Microsoft Windows;Mac OS
;Unix and Unix-like
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.- Using a terminal based client : su and sudo run in the terminal, where they are vulnerable to spoofed input. Of course, if the user was not running a multitasking environment, this would not be a problem. Terminal windows are usually rendered as ordinary windows to the user, therefore on an intelligent client or desktop system used as a client, the user must take responsibility for preventing other malware on their desktop from manipulating, simulating, or capturing input.
- Using a GUI/desktop tightly integrated to the operating system: Commonly, the desktop system locks or secures all common means of input, before requesting passwords or other authentication, so that they cannot be intercepted, manipulated, or simulated:
Fake authentication dialogs
- Though it is not the default behavior for usability reasons, UAC may be configured to require the user to press Ctrl+Alt+Del as part of the authentication process. Because only Windows can detect this key combination, requiring this additional security measure would prevent spoofed dialogs from behaving the same way as a legitimate dialog. For example, a spoofed dialog might not ask the user to press Ctrl+Alt+Del, and the user could realize that the dialog was fake. Or, when the user did press Ctrl+Alt+Del, the user would be brought to the screen Ctrl+Alt+Del normally brings them to instead of a UAC confirmation dialog. Thus the user could tell whether the dialog was an attempt to trick them into providing their password to a piece of malicious software.
- In GNOME, PolicyKit uses different dialogs, depending on the configuration of the system. For example, the authentication dialog for a system equipped with a fingerprint reader might look different from an authentication dialog for a system without one. Applications do not have access to the configuration of PolicyKit, so they have no way of knowing which dialog will appear and thus how to spoof it.
Usability considerations
Separate administrator account
- su require the user to know the password to at least two accounts: the regular-use account, and an account with higher privileges such as root.
- sudo, kdesu and gksudo use a simpler approach. With these programs, the user is pre-configured to be granted access to specific administrative tasks, but must explicitly authorize applications to run with those privileges. The user enters their own password instead of that of the superuser or some another account.
- UAC and Authenticate combine these two ideas into one. With these programs, administrators explicitly authorize programs to run with higher privileges. Non-administrators are prompted for an administrator username and password.
- PolicyKit can be configured to adopt any of these approaches. In practice, the distribution will choose one.
Simplicity of dialog
- In order to grant an application administrative privileges, sudo, gksudo, and Authenticate prompt administrators to re-enter their password.
- With UAC, when logged in as a standard user, the user must enter an administrator's name and password each time they need to grant an application elevated privileges; but when logged in as a member of the Administrators group, they simply confirm or deny, instead of re-entering their password each time. While the default approach is simpler, it is also less secure, since if the user physically walks away from the computer without locking it, another person could walk up and have administrator privileges over the system.
- PolicyKit requires the user to re-enter his or her password or provide some other means of authentication.
Saving credentials
- UAC prompts for authorization each time it is called to elevate a program.
- sudo, gksudo, and kdesu do not ask the user to re-enter their password every time it is called to elevate a program. Rather, the user is asked for their password once at the start. If the user has not used their administrative privileges for a certain period of time, the user is once again restricted to standard user privileges until they enter their password again.
- Authenticate does not save passwords. If the user is a standard user, they must enter a username and a password. If the user is an administrator, the current user's name is already filled in, and only needs to enter their password. The name can still be modified to run as another user.
- PolicyKit can be configured to adopt either of these approaches.
Identifying when administrative rights are needed
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. Different operating systems offer distinct methods for applications to identify their security requirements:
- sudo centralises all privilege authorization information in a single configuration file,
/etc/sudoers
, which contains a list of users and the privileged applications and actions that those users are permitted to use. The grammar of the sudoers file is intended to be flexible enough to cover many different scenarios, such as placing restrictions on command-line parameters. For example, a user can be granted access to change anybody's password except for the root account, as follows:
- User Account Control uses a combination of heuristic scanning and "application manifests" to determine if an application requires administrator privileges. Manifest files, first introduced with Windows XP, are XML files with the same name as the application and a suffix of ".manifest", e.g.
Notepad.exe.manifest
. When an application is started, the manifest is looked at for information about what security requirements the application has. For example, this XML fragment will indicate that the application will require administrator access, but will not require unfettered access to other parts of the user desktop outside the application:
- Applications using PolicyKit ask for specific privileges when prompting for authentication, and PolicyKit performs those actions on behalf of the application. Before authenticating, users are able to see which application requested the action and which action was requested.