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.

Introduction to implementations

Microsoft Windows
User Account Control prompt dialog box User Account Control (UAC):
Included with Windows Vista and later Microsoft Windows operating systems, UAC prompts the user for authorization when an application tries to perform an administrator task.[1]
Runas:
A command-line tool and context-menu verb introduced with Windows 2000 that allows running a program, control panel applet, or a MMC snap-in as a different user.[2] Runas makes use of the "Secondary Login" Windows service, also introduced with Windows 2000.[3] 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.
Mac OS
Mac OS X includes the Authenticate dialog, which prompts the user to input their password in order to perform administrator tasks. This is essentially a graphical front-end of sudo command.
Unix and Unix-like
PolicyKit/pkexec:
A privilege authorization feature, designed to be independent of the desktop environment in use and already adopted by GNOME[4] In contrast to earlier systems, applications using PolicyKit never run with privileges above those of the current user. Instead, they indirectly make requests of the PolicyKit daemon, which is the only program that runs as root.
Sudo, running in Terminal window in Ubuntu su:
A command line tool for Unix. su (substitute user) 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,[5] sudo is a highly configurable Unix command line tool similar to su, but it allows certain users to run programs with root privileges without spawning a root shell or requiring root's password.[6]
GKSu and GKsudo:
GTK+ Graphical frontend to su and sudo.[7] GKsu comes up automatically when a supported application needs to perform an action requiring root privileges. A replacement, "gksu PolicyKit", which uses PolicyKit rather than su/sudo, is being developed as part of GNOME.[8]
kdesu:
A Qt graphical front-end to the su command for KDE.[9]
kdesudo:
A Qt graphical front-end to sudo that has replaced kdesu in Kubuntu, starting with Kubuntu 7.10.[10]
ktsuss:
ktsuss stands for "keep the su simple, stupid", and is a graphical version of su. The idea of the project is to remain simple and bug free.
beesu:
A graphical front-end to the su command that has replaced gksu in Red Hat based operating systems. It has been developed mainly for RHEL and Fedora.[11]

Security considerations

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.

If either gksudo's "lock" feature or UAC's Secure Desktop were compromised or disabled, malicious applications could gain administrator privileges by using keystroke logging to record the administrator's password; or, in the case of UAC if running as an administrator, spoofing a mouse click on the "Allow" button. For this reason, voice recognition is also prohibited from interacting with the dialog. Note that since gksu password prompt runs without special privileges, malicious applications can still do keystroke logging using e.g. the strace tool.[14] (ptrace was restricted in later kernel versions)[15]

Spoofed 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.

Separate administrator account

Simplicity of dialog

Saving credentials

sudo's approach is a trade-off between security and usability. On one hand, a user only has to enter their password once to perform a series of administrator tasks, rather than having to enter their password for each task. But at the same time, the surface area for attack is larger because all programs that run in that tty (for sudo) or all programs not running in a terminal (for gksudo and kdesu) prefixed by either of those commands before the timeout receive administrator privileges. Security-conscious users may remove the temporary administrator privileges upon completing the tasks requiring them by using the sudo -k command when from each tty or pts in which sudo was used (in the case of pts's, closing the terminal emulator is not sufficient). The equivalent command for kdesu is kdesu -s. There is no gksudo option to do the same; however, running sudo -k not within a terminal instance (e.g. through the Alt + F2 "Run Application" dialogue box, unticking "Run in terminal") will have the desired effect.
The application only requires authentication once, and is requested at the time the application needs the privilege. Once "elevated", the application does not need to authenticate again until the application has been Quit and relaunched.
However, there are varying levels of authentication, known as Rights. The right that is requested can be shown by expanding the triangle next to "details", underneath the password. Normally, applications use system.privilege.admin, but another may be used, such as a lower right for security, or a higher right if higher access is needed. If the right the application has is not suitable for a task, the application may need to authenticate again to increase the privilege level.

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>
Manifest files can also be compiled into the application executable 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.[20]
UAC also makes a distinction between elevation requests from a signed executable and an unsigned executable; and if the former, whether or not the publisher is 'Windows Vista'. The color, icon, and wording of the prompts are different in each case: for example, attempting to convey a greater sense of warning if the executable is unsigned than if not.[21]

See also

References

  1. "User Account Control Overview". Microsoft. 2006-10-02. Retrieved 2007-03-12.
  2. "Runas". Windows XP Product Documentation. Microsoft. Retrieved 2007-03-13.
  3. ""RunAs" basic (and intermediate) topics". Aaron Margosis' WebLog. MSDN Blogs. 2004-06-23. Retrieved 2007-03-13.
  4. "About PolicyKit". PolicyKit Language Reference Manual. 2007. Retrieved 2008. Check date values in: |access-date= (help)
  5. Miller, Todd C. "A Brief History of Sudo". Retrieved 2007-03-12.
  6. 1 2 3 Miller, Todd C. "Sudo in a Nutshell". Retrieved 2007-07-01.
  7. "GKSu home page".
  8. "gksu PolicyKit on Gnome Live".
  9. Bellevue Linux (2004-11-20). "The KDE su Command". Archived from the original on 2007-02-02. Retrieved 2007-03-12.
  10. Canonical Ltd. (2007-08-25). "GutsyGibbon/Tribe5/Kubuntu". Retrieved 2007-09-18.
  11. You can read more about beesu and download it from Koji
  12. "gksu - a Gtk+ su frontend Linux Man Page". Retrieved 2007-08-14.
  13. "User Account Control Prompts on the Secure Desktop". UACBlog. Microsoft. 2006-05-03. Retrieved 2007-03-04. |first1= missing |last1= in Authors list (help)
  14. "gksu: locking mouse/keyboard not enough to protect against keylogging".
  15. "ptrace Protection".
  16. 1 2 Allchin, Jim (2007-01-23). "Security Features vs. Convenience". Windows Vista Team Blog. Microsoft. Retrieved 2007-03-12.
  17. "Authentication Agent". 2007. Retrieved 2008. Check date values in: |access-date= (help)
  18. Miller, Todd C. "Sudoers Manual". Retrieved 2007-03-12.
  19. "Developer Best Practices and Guidelines for Applications in a Least Privileged Environment". MSDN. Microsoft. Retrieved 2007-03-15.
  20. "Understanding and Configuring User Account Control in Windows Vista". TechNet. Microsoft. Retrieved 2007-03-15.
  21. "Accessible UAC Prompts". Windows Vista Blog. Microsoft.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.