Special Permissions (SetUID, SetGID and Sticky Bit) in Linux

Introduction

In Linux, the behavior of a file is set or controlled by two mechanisms: file ownership and file permissions. The ownership of files or directories is normally based on the default uid (User ID) gid (Group ID) of the the user who created them. Regarding the file permissions, a default set of permissions (755 for directories, 644 for the files) are assigned to a file or directory when it is created. If preferred, these default permissions can be changed by the umask command.

The file ownership not only determines who can access a file but also how a file behaves when it is run. This is due to the fact that when a file is executed, it runs with the effective uid and gid of the user who started it.

To change file ownership and file permissions, chown and chmod commands can be used respectively. Through the chmod command, Read (r), Write (w) or eXecute (x) privileges can be set for the owner of the file, to the group or to all the other users. In addition to these three modes (r, w, x), a set of permissions that are collectively known as special modes (SetUID, SetGID and Sticky Bit) can also be set through the chmod command to further control the file permissions.

In this article, we explain what these special file permissions (SetUID, SetGID and Sticky Bit) modes are, why they are needed and how to set or unset them with practical examples.

SetUID

As described briefly above, when a file is executed (if the execution bit is set), it runs with the effective uid and gid of the user who started it. However, this default behavior can be changed by modifying the setuid flag on the file permissions bits. When the setuid flag is set, an executable file does not run with privileges of the user who launched it, but with that of the file owner instead. So, for instance, if an executable file has its setuid bit is on and it is owned by the root, it will be executed with root privileges even when a normal user (with execute privileges) launches it.

To give an example, let’s explore the passwd command for which the default permissions are depicted below.

As the output of the ls -la command shows, the file passwd is owned by the root, i.e., its effective uid and gid are set as the root user. Also, note that the setuid bit is set for the passwd command by the bit flag s in place of the executable bit (x). This is denoted in the first octal (owner permissions) of the permissions bits.

To explain the notation a little bit more, the bit flag s denotes that both the executable (x) and the setuid flags are set while a capital S indicates that only the setuid flag is on and the executable (x) flag is not. In the latter case, the setuid permission has actually no effect as the file is not executable at all.

Going back to example, since all the other users have the read (r) and execute (x) permissions on the passwd command, when it is run by a normal user, it will be executed with the privileges of the root user, instead of the privileges of the user launching the passwd command.

So far so good. But why this setuid feature is needed and what is it good for? To answer this question, let’s have a look at the permissions on the /etc/shadow file that is being used by the /bin/passwd command under the hood to change users’ passwords.

As can be seen from the output given above, only the root user can modify this file while shadow group can only read it and the rest of the users have no permissions at all. In this case, if the passwd command did not have its setuid bit set, normal users could execute the command successfully but they would not be allowed to change any user passwords since they did not have the write permission on the /etc/shadow file.

You might further ask why the users can not change the /etc/shadow file directly to prevent all this confusion? The answer to this question is that normal users would have the full capability to change any password other than their own. However, through this carefully designed privilege mechanism, ordinary users can modify the /etc/shadow file, but with a restricted capability controlled by the /bin/passwd command that allows users only to change their own passwords. Actually, this example demonstrates a good example of the Least Privilege Principle for secure system design.

To set the setuid bit, you can use the following commands, with numerical and symbolic notations respectively.

$ chmod 4644 filename

$ chmod u+s filename

To unset the setuid bit, you can use the following commands, with numerical and symbolic notations respectively.

$ chmod 0644 filename

$ chmod u-s filename

To search for the files that are owned by the root user and have their setuid bit set, you can use the following commands.

$ find / -user root -perm -4000 -ls 2> /dev/null

$ find / -user root -perm -u=s -ls 2> /dev/null

As depicted below, sudo command is another good example for the setuid special permission. Through the capability provided by the setuid flag on the sudo command, normal users can run other commands with the privileges of the root user.

SetGID

The setgid bit is very similar in functionality to the setuid bit except that it affects both files as well as directories. When set on a file, it is run with the privileges of the group which own the file rather than the user who launched it. In the case of setting the setgid bit on a directory, files created inside that directory will be owned by the group that of the parent directory rather than the group to which the user, who created the file, belongs to.

The setgid flag is represented with an s character in the second octal (group permissions) of the file permission bits.

To set the setgid bit, you can use the following commands, with numerical and symbolic notations respectively.

$ chmod 2644 filename

$ chmod g+s filename

To unset the setgid bit, you can use the following commands, with numerical and symbolic notations respectively.

$ chmod 0644 filename

$ chmod g-s filename

To locate the files that are owned by the root user and have their setgid bit set, you can use the following commands.

$ find / -user root -perm -2000 -ls 2> /dev/null

$ find / -user root -perm -g=s -ls 2> /dev/null

For instance, the crontab command runs with the privileges of the crontab group irrespective of the user who launches it.

Security Concerns over SetUID and SetGID

As explained above, both the SetUID and SetGID are necessary rather than being extraneous features in Linux. However, they should be used only when necessary and carefully. Again, as discussed briefly above, this is what the Least Privilege Principle dictates as a best security principle.

Secondly and more importantly, these privilege bits could lead to serious security issues due to the risk that they could allow attackers to conduct privilege escalation attacks. If a file that has its SetUID or SetGID bit set is vulnerable to Buffer Overflow attacks, then attackers can run their malicious code with the root privileges by corrupting the memory. Thus, only executables which are considered to be secure should be assigned the SetUID or SetGID privileges. To minimize the security risks, some operating systems even ignore these bits for executable shell scripts.

Sticky Bit

The last of the special permissions, sticky bit is only used with the directories and has no effect on files. When a directory has its sticky bit set, the files that it contains can still be accessed or modified according the file permissions. However, only the file owner, directory owner or the root user can only rename or delete these files. In other terms, sticky bit further can specify who can delete or rename the files contained in a directory in addition to the regular file permissions.

The sticky bit flag is represented with a t character in the third octal (other user permissions) of the file permission bits.

To set the sticky bit, you can use the following commands, with numerical and symbolic notations respectively.

$ chmod 1644 directoryname

$ chmod +t directoryname

To unset the sticky bit, you can use the following commands, with numerical and symbolic notations respectively.

$ chmod 0644 directoryname

$ chmod -t directoryname

To search for the directories that have their stick bit set, you can use the following commands.

$ find / -perm -1000 2> -ls /dev/null

$ find / -perm -o=t 2> -ls /dev/null

To give an example, the /tmp directory has its sticky bit flag set, so that files created under this directory can only be deleted or renamed by the owner, or the root user. Thus other users can not delete it accidentally or deliberately.

To learn more on Linux, you could also read our article Basic Linux Commands for Beginners or visit Linux Resources Page.