Comparison of privilege authorization features

From Wikipedia, the free encyclopedia

A number of computer operating systems employ security features to reduce the ability of administrators from giving malware sufficient privileges to compromise the computer system. Previously to the rise of this concept, operating systems such as DOS and Windows 95 gave administrator privileges to all programs running on an administrator account. The problem was that this also gave malware, viruses, worms, etc. administrator privileges as well. With these privileges, malicious software could wreak havoc on the operating system.

To combat this problem, modern operating systems use one or two methods. The simple method is to give users limited-privilege accounts, switching to a higher-privileged account only when necessary. Another method is to have users run with administrative privileges as before, but require explicit permission to grant a process administrator rights.

This article aims to centralize information about the similarities and differences between implementations of these methods and the level of security offered by each.

Contents

[edit] Introduction to implementations

  • su is a manually invoked command line tool for Unix. It allows users to switch the terminal to a different account by entering the username and password of that account. If no user name is given, the operating system's superuser account (known as "root") is used, thus providing a fast method to obtain a login shell with full privileges to the system. Issuing an exit command returns the user to their own account.
  • sudo, created around 1980,[1] is a manually invoked Unix command line tool similar to su, but it allows certain users to run programs with root privileges instead of having to switch to the root account.[2]
  • gksudo is a graphical frontend to sudo included with Ubuntu. It comes up automatically when an application tries to perform an action requiring root privileges.
  • kdesu is a graphical front-end to the su command.[3]
  • Mac OS X includes the Authenticate dialog, which prompts the user to input their password in order to perform administrator tasks.
  • User Account Control (UAC), a feature of Windows Vista, prompts the user for authorization when an application tries to perform an administrator task.[4]
  • runas is a command-line tool introduced with Windows 2000 that allows running a program, control panel applet, or a MMC snap-in as a different user.[5] Runas makes use of the "Secondary Login" Windows service, also introduced with Windows 2000.[6] This service provides the capability to allow applications running as a separate user to interact with the logged-in user's desktop. This is necessary to support drag-and-drop, clipboard sharing, and other interactive login features.


[edit] Security considerations

[edit] Spoofed 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.

  • 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 (i.e. in the shell only), there would be no problem.
  • By default, gksudo "locks" the keyboard, mouse, and window focus,[7] preventing anything but the actual user from inputting the password or otherwise interfering with the confirmation dialog.
  • By default, UAC runs in the Secure Desktop, preventing malicious applications from simulating clicking the "Allow" button or otherwise interfering with the confirmation dialog.[8] In this mode, the user's desktop appears dimmed and cannot be interacted with.

[edit] Spoofed dialogs

Another security consideration is the ability of malicious software to spoof dialogs that look like legitimate security confirmations. 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 was disabled, the malicious software could use that password to gain higher privileges.

  • Though it is not the default behavior for usability reasons, UAC may be configured to require the user to press Ctrl+Alt+Del (known as the secure attention sequence) 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.[9] For example, a spoofed dialog might not ask the user to press Ctrl+Alt+Del, and the user would know 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 would be able to tell whether the dialog was an attempt to trick the user into providing their password to a piece of malicious software.

[edit] Usability considerations

One consideration that has gone into these implementations is usability, or in other words, ease of use.

[edit] Separate administrator account

  • su and kdesu require the user to know the password to at least two accounts: the regular-use account, and an account with higher priviliges such as root.
  • sudo 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 as password.

[edit] Simplicity of dialog

  • In order to grant an application administrative priviliges, sudo,[10] gksudo, and Authenticate prompt administrators to re-enter their password.
  • By default in UAC, an administrator simply confirms or denies an action, instead of re-entering their password each time. While this approach is simpler, it is a little less secure.[9] If the user physically walked away from the computer, another person could walk up and have administrator privileges over the system. Also, if the security of the Secure Desktop was compromised in some way, or the Secure Desktop was disabled, malicious applications would easily be able to gain administrator privileges by spoofing a mouse click on the "Allow" button, or by using keystroke logging to record the administrator's password.

[edit] 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 was 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 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 adminstrators should see). Different operating systems offer distinct methods for applications to identify their security requirements:

  • setuid is a file-system permissions flag on Unix-like systems that can be applied to any binary. This flag tells the operating system that the application in question will need to operate as another user. This is typically used to run an application as root, which is the only user capable of performing certain operations (such as opening a TCP port under 1025). ping is an example of an application that is setuid root.
  • sudo centralises all privilege authorization information in a a single configuration file, /etc/sudoers, which contains a list of users and the 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:
 pete    ALL = /usr/bin/passwd [A-z]*, !/usr/bin/passwd root
  • User Account Control uses a combination of hueristic scanning and "application manifests" to determine if an application requires administrator privileges.[11] 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:
 <security>
   <requestedPrivileges>
     <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
   </requestedPrivileges>
 </security>
Manifest files can also be compiled into the application exectuable itself as an embedded resource.
Heuristic scanning is also used, primarily for backwards compatibility. One example of this is looking at the executable's file name; if it contains the word "Setup", it is assumed that the executable is an installer, and a UAC prompt is displayed before the application starts.[12]

[edit] See also

[edit] References

  1. ^ Miller, Todd C. A Brief History of Sudo. Retrieved on 2007-03-12.
  2. ^ Miller, Todd C. Sudo in a Nutshell. Retrieved on 2007-03-12.
  3. ^ Bellevue Linux (2004-11-20). The KDE su Command. Retrieved on 2007-03-12.
  4. ^ User Account Control Overview. Microsoft (2006-10-02). Retrieved on 2007-03-12.
  5. ^ Runas. Windows XP Product Documentation. Microsoft. Retrieved on 2007-03-13.
  6. ^ "RunAs" basic (and intermediate) topics. Aaron Margosis' WebLog. MSDN Blogs (2004-06-23). Retrieved on 2007-03-13.
  7. ^ Translations made by Irvin Piraman. Retrieved on 2007-03-12.
  8. ^ User Account Control Prompts on the Secure Desktop. UACBlog. Microsoft (2006-05-03). Retrieved on 2007-03-04.
  9. ^ a b Allchin, Jim (2007-01-23). Security Features vs. Convenience. Windows Vista Team Blog. Microsoft. Retrieved on 2007-03-12.
  10. ^ Miller, Todd C. Sudoers Manual. Retrieved on 2007-03-12.
  11. ^ Developer Best Practices and Guidelines for Applications in a Least Privileged Environment. MSDN. Microsoft. Retrieved on 2007-03-15.
  12. ^ Understanding and Configuring User Account Control in Windows Vista. TechNet. Microsoft. Retrieved on 2007-03-15.