Setuid

Last updated

The Unix and Linux access rights flags setuid and setgid (short for set user identity and set group identity) [1] allow users to run an executable with the file system 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 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.

Contents

The flags setuid and setgid are needed for tasks that require different privileges than what the user is normally granted, such as the ability to alter system files or databases to change their login password. [2] Some of the tasks that require additional privileges may not immediately be obvious, though, such as the ping command, which must send and listen for control packets on a network interface.

File modes

The setuid and setgid bits are normally represented as the values 4 for setuid and 2 for setgid in the high-order octal digit of the file mode. For example, 6711 has both the setuid and setgid bits (4 + 2 = 6) set, and also the file read/write/executable for the owner (7), and executable by the group (first 1) and others (second 1). Most implementations have a symbolic representation of these bits; in the previous example, this could be u=rwx,go=x,ug+s.

Typically, chmod does not have a recursive mode restricted to directories, so modifying an existing directory tree must be done manually, with a command such as find/path/to/directory-typed-execchmodg+s'{}''\'.

Effects

The setuid and setgid flags have different effects, depending on whether they are applied to a file, to a directory or binary executable or non-binary executable file. The setuid and setgid flags have an effect only on binary executable files and not on scripts (e.g., Bash, Perl, Python). [3]

When set on an executable file

When the setuid or setgid attributes are set on an executable file, then any users able to execute the file will automatically execute the file with the privileges of the file's owner (commonly root) and/or the file's group, depending upon the flags set. [2] This allows the system designer to permit trusted programs to be run which a user would otherwise not be allowed to execute. These may not always be obvious. For example, the ping command may need access to networking privileges that a normal user cannot access; therefore it may be given the setuid flag to ensure that a user who needs to ping another system can do so, even if their account does not have the required privilege for sending packets.

Security impact

For security purposes, the invoking user is usually 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, to exploit the raised privilege, although signals from the terminal will still be accepted.

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, [4] many operating systems ignore the setuid attribute when applied to executable shell scripts .[ citation needed ]

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.

When set on a directory

Setting the setgid permission on a directory causes files and subdirectories created within to inherit its group ownership, rather than the primary group of the file-creating process. Created subdirectories also inherit the setgid bit. The policy is only applied during creation and, thus, only prospectively. Directories and files existing when the setgid bit is applied are unaffected, as are directories and files moved into the directory on which the bit is set.

Thus is granted a capacity to work with files amongst a group of users without explicitly setting permissions, but limited by the security model expectation that existing files permissions do not implicitly change.

The setuid permission set on a directory is ignored on most UNIX and Linux systems. [5] [ citation needed ] However FreeBSD can be configured to interpret setuid in a manner similar to setgid, in which case it forces all files and sub-directories created in a directory to be owned by that directory's owner - a simple form of inheritance. [6] This is generally not needed on most systems derived from BSD, since by default directories are treated as if their setgid bit is always set, regardless of the 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." [7]

Examples

Checking permissions

Permissions of a file can be checked in octal form and/or alphabetic form with the command line tool stat

[ torvalds ~ ] $ stat-c"%a %A"~/test/ 1770 drwxrwx--T

SUID

4701 on an executable file owned by 'root' and the group 'root'

A user named 'thompson' attempts to execute the file. The executable permission for all users is set (the '1') so 'thompson' 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 an executable would be run as 'root' is so that it can modify specific files that the user would not normally be allowed to, without giving the user full root access.

A default use of this can be seen with the /usr/bin/passwd binary file. /usr/bin/passwd needs to modify /etc/passwd and /etc/shadow which store account information and password hashes for all users, and these can only be modified by the user 'root'.

[ thompson ~ ] $ stat-c"%a %U:%G %n"/usr/bin/passwd 4701 root:root /usr/bin/passwd[ thompson ~ ] $ passwd passwd: Changing password for thompson

The owner of the process is not the user running the executable file but the owner of the executable file

SGID

2770 on a directory named 'music' owned by the user 'root' and the group 'engineers'

A user named 'torvalds' who belongs primarily to the group 'torvalds' but secondarily to the group 'engineers' makes a directory named 'electronic' under the directory named 'music'. The group ownership of the new directory named 'electronic' inherits 'engineers.' This is the same when making a new file named 'imagine.txt'

Without SGID the group ownership of the new directory/file would have been 'torvalds' as that is the primary group of user 'torvalds'.

[ torvalds ~ ] $ groupstorvalds torvalds : torvalds engineers[ torvalds ~ ] $ stat-c"%a %U:%G %n"./music/ 2770 root:engineers ./music/[ torvalds ~ ] $ mkdir./music/electronic  [ torvalds ~ ] $ stat-c"%U:%G %n"./music/electronic/ torvalds:engineers ./music/electronic/[ torvalds ~ ] $ echo'NEW FILE'>./music/imagine.txt  [ torvalds ~ ] $ stat-c"%U:%G %n"./music/imagine.txt torvalds:engineers ./music/imagine.txt[ torvalds ~ ] $ touch~/test  [ torvalds ~ ] $ stat-c"%U:%G %n"~/test torvalds:torvalds ~/test

Sticky bit

1770 on a directory named 'videogames' owned by the user 'torvalds' and the group 'engineers'.

A user named 'torvalds' creates a file named 'tekken' under the directory named 'videogames'. A user named 'wozniak', who is also part of the group 'engineers', attempts to delete the file named 'tekken' but he cannot, since he is not the owner.

Without sticky bit, 'wozniak' could have deleted the file, because the directory named 'videogames' allows read and write by 'engineers'. A default use of this can be seen at the /tmp folder.

[ torvalds /home/shared/ ] $ groupstorvalds torvalds : torvalds engineers[ torvalds /home/shared/ ] $ stat-c"%a  %U:%G  %n"./videogames/ 1770  torvalds:engineers  ./videogames/[ torvalds /home/shared/ ] $ echo'NEW FILE'>videogames/tekken  [ torvalds /home/shared/ ] $ su-wozniak Password:[ wozniak ~/ ] $ groupswozniak wozniak : wozniak engineers[ wozniak ~/ ] $ cd/home/shared/videogames  [ wozniak /home/shared/videogames/ ] $ rmtekken rm: cannot remove ‘tekken’: Operation not permitted

Sticky bit with SGID

3171 on a directory named 'blog' owned by the group 'engineers' and the user 'root'

A user named 'torvalds' who belongs primarily to the group 'torvalds' but secondarily to the group 'engineers' creates a file or directory named 'thoughts' inside the directory 'blog'. A user named 'wozniak' who also belongs to the group 'engineers' cannot delete, rename, or move the file or directory named 'thoughts', because he is not the owner and the sticky bit is set. However, if 'thoughts' is a file, then 'wozniak' can edit it.

Sticky bit has the final decision. If sticky bit and SGID had not been set, the user 'wozniak' could rename, move, or delete the file named 'thoughts' because the directory named 'blog' allows read and write by group, and wozniak belongs to the group, and the default 0002 umask allows new files to be edited by group. Sticky bit and SGID could be combined with something such as a read-only umask or an append only attribute.

[ torvalds /home/shared/ ] $ groupstorvalds torvalds : torvalds engineers[ torvalds /home/shared/ ] $ stat-c"%a  %U:%G  %n"./blog/ 3171  root:engineers  ./blog/[ torvalds /home/shared/ ] $ echo'NEW FILE'>./blog/thoughts  [ torvalds /home/shared/ ] $ su-wozniak Password:[ wozniak ~/ ] $ cd/home/shared/blog  [ wozniak /home/shared/blog/ ] $ groupswozniak wozniak : wozniak engineers[ wozniak /home/shared/blog/ ] $ stat-c"%a  %U:%G  %n"./thoughts 664  torvalds:engineers  ./thoughts[ wozniak /home/shared/blog/ ] $ rmthoughts rm: cannot remove ‘thoughts’: Operation not permitted[ wozniak /home/shared/blog/ ] $ mvthoughts/home/wozniak/ mv: cannot move ‘thoughts’ to ‘/home/wozniak/thoughts’: Operation not permitted[ wozniak /home/shared/blog/ ] $ mvthoughtspondering mv: cannot move ‘thoughts’ to ‘pondering’: Operation not permitted[ wozniak /home/shared/blog/ ] $ echo'REWRITE!'>thoughts  [ wozniak /home/shared/blog/ ] $ catthoughts REWRITE!

Security

Developers 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. [8] 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. [9]

History

The setuid bit was invented by Dennis Ritchie [10] and included in su . [10] 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. [11]

See also

Related Research Articles

In Unix and Unix-like operating systems, chmod is the command and system call used to change the access permissions and the special mode flags of file system objects. Collectively these were originally called its modes, and the name chmod was chosen as an abbreviation of change mode.

A shared library or shared object is a computer file that contains executable code designed to be used by multiple computer programs or other libraries at runtime.

ls Command to list files and directories in Unix and Unix-like operating systems

In computing, ls is a command to list computer files and directories in Unix and Unix-like operating systems. It is specified by POSIX and the Single UNIX Specification.

Unix security refers to the means of securing a Unix or Unix-like operating system.

In computing, the superuser is a special user account used for system administration. Depending on the operating system (OS), the actual name of this account might be root, administrator, admin or supervisor. In some cases, the actual name of the account is not the determining factor; on Unix-like systems, for example, the user with a user identifier (UID) of zero is the superuser [i.e., uid=0], regardless of the name of that account; and in systems which implement a role-based security model, any user with the role of superuser can carry out all actions of the superuser account. The principle of least privilege recommends that most users and applications run under an ordinary account to perform their work, as a superuser account is capable of making unrestricted, potentially adverse, system-wide changes.

The Unix command su, which stands for 'substitute user', is used by a computer user to execute commands with the privileges of another user account. When executed it invokes a shell without changing the current working directory or the user environment.

passwd Tool to change passwords on Unix-like OSes

passwd is a command on Unix, Plan 9, Inferno, and most Unix-like operating systems used to change a user's password. The password entered by the user is run through a key derivation function to create a hashed version of the new password, which is saved. Only the hashed version is stored; the entered password is not saved for security reasons.

chroot Operation that changes the apparent root directory in Unix-like systems

chroot is an operation on Unix and Unix-like operating systems that changes the apparent root directory for the current running process and its children. A program that is run in such a modified environment cannot name files outside the designated directory tree. The term "chroot" may refer to the chroot(2) system call or the chroot(8) wrapper program. The modified environment is called a chroot jail.

Files-11 is the file system used in the RSX-11 and OpenVMS operating systems from Digital Equipment Corporation. It supports record-oriented I/O, remote network access, and file versioning. The original ODS-1 layer is a flat file system; the ODS-2 version is a hierarchical file system, with support for access control lists,.

In computing, umask is a command that determines the settings of a mask that controls how file permissions are set for newly created files. It may also affect how the file permissions are changed explicitly. umask is also a function that sets the mask, or it may refer to the mask itself, which is formally known as the file mode creation mask. The mask is a grouping of bits, each of which restricts how its corresponding permission is set for newly created files. The bits in the mask may be changed by invoking the umask command.

In computer programming and computer security, privilege separation (privsep) is one software-based technique for implementing the principle of least privilege. With privilege separation, a program is divided into parts which are limited to the specific privileges they require in order to perform a specific task. This is used to mitigate the potential damage of a computer security vulnerability.

In Unix-like systems, multiple users can be put into groups. POSIX and conventional Unix file system permissions are organized into three classes, user, group, and others. The use of groups allows additional abilities to be delegated in an organized fashion, such as access to disks, printers, and other peripherals. This method, among others, also enables the superuser to delegate some administrative tasks to normal users, similar to the Administrators group on Microsoft Windows NT and its derivatives.

Most file systems include attributes of files and directories that control the ability of users to read, change, navigate, and execute the contents of the file system. In some cases, menu options or functions may be made visible or hidden depending on a user's permission level; this kind of user interface is referred to as permission-driven.

The seven standard Unix file types are regular, directory, symbolic link, FIFO special, block special, character special, and socket as defined by POSIX. Different OS-specific implementations allow more types than what POSIX requires. A file's type can be identified by the ls -l command, which displays the type in the first character of the file-system permissions field.

Unix-like operating systems identify a user by a value called a user identifier, often abbreviated to user ID or UID. The UID, along with the group identifier (GID) and other access control criteria, is used to determine which system resources a user can access. The password file maps textual user names to UIDs. UIDs are stored in the inodes of the Unix file system, running processes, tar archives, and the now-obsolete Network Information Service. In POSIX-compliant environments, the shell command id gives the current user's UID, as well as more information such as the user name, primary user group and group identifier (GID).

In computing, privilege is defined as the delegation of authority to perform security-relevant functions on a computer system. A privilege allows a user to perform an action with security consequences. Examples of various privileges include the ability to create a new user, install software, or change kernel functions.

File attributes are a type of metadata that describe and may modify how files and/or directories in a filesystem behave. Typical file attributes may, for example, indicate or specify whether a file is visible, modifiable, compressed, or encrypted. The availability of most file attributes depends on support by the underlying filesystem where attribute data must be stored along with other control structures. Each attribute can have one of two states: set and cleared. Attributes are considered distinct from other metadata, such as dates and times, filename extensions or file system permissions. In addition to files, folders, volumes and other file system objects may have attributes.

In computing, the sticky bit is a user ownership access right flag that can be assigned to files and directories on Unix-like systems.

A directory traversal attack exploits insufficient security validation or sanitization of user-supplied file names, such that characters representing "traverse to parent directory" are passed through to the operating system's file system API. An affected application can be exploited to gain unauthorized access to the file system.

"Everything is a file" is an approach to interface design in Unix derivatives. While this turn of phrase does not as such figure as a Unix design principle or philosophy, it is a common way to analyse designs, and informs the design of new interfaces in a way that prefers, in rough order of import:

  1. representing objects as file descriptors in favour of alternatives like abstract handles or names,
  2. operating on the objects with standard input/output operations returning byte streams to be interpreted by applications, and
  3. allowing the usage or creation of objects by opening or creating files in the global filesystem name space.

References

  1. ↑ von Hagen, William (2010-05-13). Ubuntu Linux Bible. John Wiley & Sons. pp. 3–59. ISBN   9780470881804.
  2. 1 2 3 Frisch, Æleen (2009-02-09). Essential system administration. O'Reilly. p. 351. ISBN   9780596550493.
  3. ↑ Billimoria, Kaiwan N. (2018). Hands-On System Programming with Linux: Explore Linux system programming interfaces, theory, and practice. Packt Publishing Ltd. p. 250. ISBN   978-1-78899-674-7.
  4. ↑ "Unix - Frequently Asked Questions".
  5. ↑ "27.5 Directories and the Set-User-ID and Set-Group-ID Bits". GNU Coreutils 9.1. Free Software Foundation. Retrieved 13 December 2022.
  6. ↑ "chmod -- change file modes". freebsd.org.
  7. ↑ "open, openat -- open or create a file for reading, writing or executing". freebsd.org.
  8. ↑ Brown, Neil (November 23, 2010). "Ghosts of Unix past, part 4: High-maintenance designs". LWN.net. Retrieved 30 March 2014.
  9. ↑ Edge, Jake (October 27, 2010). "Two glibc vulnerabilities". LWN.net. Retrieved 30 March 2014.
  10. 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.
  11. ↑ "Summary of key software patents".
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.