setuid

setuid and setgid (short for "set user ID upon execution" and "set group ID upon execution", respectively)[1] are Unix access rights flags that allow users to run an executable with the permissions of the executable's owner or group respectively and to change behaviour in directories. They are often used to allow users on a computer system to run programs with temporarily elevated privileges in order to perform a specific task. While the assumed user id or group id privileges provided are not always elevated, at a minimum they are specific.

setuid and setgid are needed for tasks that require higher privileges than those which common users have, such as changing their login password.[2] Some of the tasks that require elevated privileges may not immediately be obvious, though — such as the ping command, which must send and listen for control packets on a network interface.

setuid and setgid on executables

When an executable file has been given the setuid attribute, normal users on the system who have permission to execute this file gain the privileges of the user who owns the file (commonly root) within the created process.[2] When root privileges have been gained within the process, the application can then perform tasks on the system that regular users normally would be restricted from doing. The invoking user will be prohibited by the system from altering the new process in any way, such as by using ptrace, LD_LIBRARY_PATH or sending signals to it (signals from the terminal will still be accepted, however).

While the setuid feature is very useful in many cases, its improper use can pose a security risk[2] if the setuid attribute is assigned to executable programs that are not carefully designed. Due to potential security issues,[3] many operating systems ignore the setuid attribute when applied to executable shell scripts.

The setgid attribute will allow for changing the group-based privileges within a process, like the setuid flag does for user-based privileges.

The presence of setuid executables explains why the chroot system call is not available to non-root users on Unix. See limitations of chroot for more details.

The setuid and setgid bits are normally set with the command chmod by setting the high-order octal digit to 4 for setuid or 2 for setgid. "chmod 6711 file" will set both the setuid and setgid bits (4+2=6), making the file read/write/executable for the owner (7), and executable by the group (first 1) and others (second 1). When a user other than the owner executes the file, the process will run with user and group permissions set upon it by its owner. For example, if the file is owned by user root and group wheel, it will run as root:wheel no matter who executes the file.

Most implementations of the chmod command also support finer-grained, symbolic arguments to set these bits. This is shown in the demonstration below as the "chmod ug+s"

setuid and setgid on directories

The setuid and setgid flags, when set on a directory, have an entirely different meaning.

Setting the setgid permission on a directory ("chmod g+s") causes new files and subdirectories created within it to inherit its group ID, rather than the primary group ID of the user who created the file (the owner ID is never affected, only the group ID). Newly created subdirectories inherit the setgid bit. Thus, this enables a shared workspace for a group without the inconvenience of requiring group members to explicitly change their current group before creating new files or directories. Note that setting the setgid permission on a directory only affects the group ID of new files and subdirectories created after the setgid bit is set, and is not applied to existing entities. Setting the setgid bit on existing subdirectories must be done manually, with a command such as the following:

root@foo# find /path/to/directory -type d -exec chmod g+s '{}' \;

The setuid permission set on a directory is ignored on UNIX and Linux systems.[4] FreeBSD can be configured to interpret it analogously to setgid, namely, to force all files and sub-directories to be owned by the top directory owner.[5]

On systems derived from BSD, directories behave as if their setgid bit was always set, regardless of its actual value. As is stated in open(2), "When a new file is created it is given the group of the directory which contains it."

Common use examples

4711

SUID on an executable file owned by "root"

A user named "tails" attempts to execute the file. The executable permission for all users is set (the second '1') so "tails" can execute the file. The file owner is "root" and the SUID permission is set (the '4')—so the file is executed as "root".

The reason the executable is run as "root" is so that it can modify files that the user "tails" would not normally be allowed to. A default use of this can be seen with the /usr/bin/passwd binary file. passwd needs to modify /etc/passwd and /etc/shadow which store account information and password hashes for all users and can only be modified by "root".

2070

GUID on a directory named "planets" owned by the group "doctors" and the user "root"

A user named "tails" who belongs primarily to the group "tails" but secondarily to the group "doctors" makes a new file or directory named "neptune" under the directory named "planets." The group ownership of the new file or directory named "neptune" inherits "doctors."

Without GUID the group ownership would have been "tails."

1077

sticky bit on a directory named "planets" owned by the group "doctors" and the user "root"

A user named "tails" creates a file named "neptune" under the directory named "planets." A user named "knuckles" attempts to delete the file named "neptune" but he cannot, since he is not the owner.

Without sticky bit "knuckles" could have deleted the file, because the directory named "planets" allows read and write by others. A default use of this can be seen with the /tmp folder.

3077

sticky bit with GUID on a directory named "planets" owned by the group "doctors" and the user "root"

A user named "tails" who belongs to the group "doctors" creates a file or directory named "neptune" inside the directory named "planets." A user named "knuckles" who also belongs to the group "doctors" cannot delete, rename, or move the file or directory named "neptune," because he is not the owner. However, if "neptune" is a file, then "knuckles" can edit it.

If sticky bit and GUID had not been set, the user "knuckles" could rename, move, or delete the file named "neptune" because the directory named "planets" allows read and write by others. Sticky bit and GUID could be combined with something such as a read-only umask or an append only attribute

Security

Developers should design and implement programs that use this bit on executables carefully in order to avoid security vulnerabilities including buffer overruns and path injection. Successful buffer-overrun attacks on vulnerable applications allow the attacker to execute arbitrary code under the rights of the process exploited. In the event that a vulnerable process uses the setuid bit to run as root, the code will execute with root privileges, in effect giving the attacker root access to the system on which the vulnerable process is running.

Of particular importance in the case of a setuid process is the environment of the process. If the environment is not properly sanitized by a privileged process, its behavior can be changed by the unprivileged process that started it.[6] For example, GNU libc was at one point vulnerable to an exploit using setuid and an environment variable that allowed executing code from untrusted shared libraries.[7]

History

The setuid bit was invented by Dennis Ritchie[8] and included in su.[8] His employer, then Bell Telephone Laboratories, applied for a patent in 1972; the patent was granted in 1979 as patent number US 4135240  "Protection of data file contents". The patent was later placed in the public domain.[9]

See also

References

  1. ↑ von Hagen, William (2010-05-13). Ubuntu Linux Bible. pp. 3–59. ISBN 9780470881804.
  2. 1 2 3 Frisch, Æleen (2009-02-09). Essential system administration. O'Reilly. p. 351. ISBN 9780596550493.
  3. ↑ "Unix - Frequently Asked Questions".
  4. ↑ Bauer, Mick (2004). "Paranoid Penguin - Linux Filesystem Security, Part II". linuxjournal.com.
  5. ↑ "chmod manpage on www.freebsd.org".
  6. ↑ Neil Brown (November 23, 2010). "Ghosts of Unix past, part 4: High-maintenance designs". LWN.net. Retrieved 30 March 2014.
  7. ↑ Jake Edge (October 27, 2010). "Two glibc vulnerabilities". LWN.net. Retrieved 30 March 2014.
  8. 1 2 McIlroy, M. Douglas (1987). A Research Unix reader: annotated excerpts from the Programmer's Manual, 1971–1986 (PDF) (Technical report). CSTR. Bell Labs. 139.
  9. ↑ "Summary of key software patents".

External links

This article is issued from Wikipedia - version of the Wednesday, April 13, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.