Three special types of permissions are available for executable files and public directories: setuid, setgid, and sticky bit. When these permissions are set, any user who runs that executable file assumes the ID of the owner (or group) of the executable file.
You must be extremely careful when you set special permissions, because special permissions constitute a security risk. For example, a user can gain superuser capabilities by executing a program that sets the user ID (UID) to 0, which is the UID of root. Also, all users can set special permissions for files that they own, which constitutes another security concern.
You should monitor your system for any unauthorized use of the setuid permission and the setgid permission to gain superuser capabilities. A suspicious permission grants ownership of an administrative program to a user rather than to root or bin. To search for and list all files that use this special permission, see How to Find Files With Special File Permissions.
setuid Permission
When setuid permission is set on an executable file, a process that runs this file is granted access on the basis of the owner of the file. The access is not based on the user who is running the executable file. This special permission allows a user to access files and directories that are normally available only to the owner.
For example, the setuid permission on the passwd command makes it possible for users to change passwords. A passwd command with setuid permission would resemble the following:
-r-sr-sr-x 3 root sys 28144 Jun 17 12:02 /usr/bin/passwd
This special permission presents a security risk. Some determined users can find a way to maintain the permissions that are granted to them by the setuid process even after the process has finished executing.
Note – The use of setuid permissions with the reserved UIDs (0–100) from a program might not set the effective UID correctly. Use a shell script, or avoid using the reserved UIDs withsetuid permissions.
setgid Permission
The setgid permission is similar to the setuid permission. The process’s effective group ID (GID) is changed to the group that owns the file, and a user is granted access based on the permissions that are granted to that group. The /usr/bin/mail command has setgid permissions:
-r-x--s--x 1 root mail 67504 Jun 17 12:01 /usr/bin/mail
When the setgid permission is applied to a directory, files that were created in this directory belong to the group to which the directory belongs. The files do not belong to the group to which the creating process belongs. Any user who has write and execute permissions in the directory can create a file there. However, the file belongs to the group that owns the directory, not to the group that the user belongs to.
You should monitor your system for any unauthorized use of the setgid permission to gain superuser capabilities. A suspicious permission grants group access to such a program to an unusual group rather than to root or bin. To search for and list all files that use this permission, see How to Find Files With Special File Permissions.
Sticky Bit
The sticky bit is a permission bit that protects the files within a directory. If the directory has the sticky bit set, a file can be deleted only by the file owner, the directory owner, or by a privileged user. The root user is an example of a privileged user. The sticky bit prevents a user from deleting other users’ files from public directories such as /tmp:
drwxrwxrwt 7 root sys 400 Sep 3 13:37 tmp
Be sure to set the sticky bit manually when you set up a public directory on a TMPFS file system.
Numeric representation
Octal digit Binary value Meaning
0 000 setuid, setgid, sticky bits are cleared
1 001 sticky bit is set
2 010 setgid bit is set
3 011 setgid and sticky bits are set
4 100 setuid bit is set
5 101 setuid and sticky bits are set
6 110 setuid and setgid bits are set
7 111 setuid, setgid, sticky bits are set
Textual representation
SUID, If set, then replaces “x” in the owner permissions to “s”, if owner has execute permissions, or to “S” otherwise.
Examples:
-rws—— both owner execute and SUID are set
-r-S—— SUID is set, but owner execute is not set
SGID, If set, then replaces “x” in the group permissions to “s”, if group has execute permissions, or to “S” otherwise.
Examples:
-rwxrws— both group execute and SGID are set
-rwxr-S— SGID is set, but group execute is not set
Sticky, If set, then replaces “x” in the others permissions to “t”, if others have execute permissions, or to “T” otherwise.
Examples:
-rwxrwxrwt both others execute and sticky bit are set
-rwxrwxr-T sticky bit is set, but others execute is not set
Setting the sticky bit on a directory : chmod +t
If you have a look at the /tmp permissions, in most GNU/Linux distributions, you’ll see the following:
lokams@tempsrv# ls -l | grep tmp drwxrwxrwt 10 root root 4096 2006-03-10 12:40 tmp
The “t” in the end of the permissions is called the “sticky bit”. It replaces the “x” and indicates that in this directory, files can only be deleted by their owners, the owner of the directory or the root superuser. This way, it is not enough for a user to have write permission on /tmp, he also needs to be the owner of the file to be able to delete it.
In order to set or to remove the sticky bit, use the following commands:
# chmod +t tmp # chmod -t tmp
Setting the SGID attribute on a directory : chmod g+s
If the SGID (Set Group Identification) attribute is set on a directory, files created in that directory inherit its group ownership. If the SGID is not set the file’s group ownership corresponds to the user’s default group.
In order to set the SGID on a directory or to remove it, use the following commands:
# chmod g+s directory # chmod g-s directory
When set, the SGID attribute is represented by the letter “s” which replaces the “x” in the group permissions:
# ls -l directory drwxrwsr-x 10 george administrators 4096 2006-03-10 12:50 directory
Setting SUID and SGID attributes on executable files : chmod u+s, chmod g+s
By default, when a user executes a file, the process which results in this execution has the same permissions as those of the user. In fact, the process inherits his default group and user identification.
If you set the SUID attribute on an executable file, the process resulting in its execution doesn’t use the user’s identification but the user identification of the file owner.
For instance, consider the script myscript.sh which tries to write things into mylog.log :
# ls -l -rwxrwxrwx 10 george administrators 4096 2006-03-10 12:50 myscript.sh -rwxrwx--- 10 george administrators 4096 2006-03-10 12:50 mylog.log
As you can see in this example, George gave full permissions to everybody on myscript.sh but he forgot to do so on mylog.log. When Robert executes myscript.sh, the process runs using Robert’s user identification and Robert’s default group (robert:senioradmin). As a consequence, myscript fails and reports that it can’t write in mylog.log.
In order to fix this problem George could simply give full permissions to everybody on mylog.log. But this would make it possible for anybody to write in mylog.log, and George only wants this file to be updated by his myscript.sh program. For this he sets the SUID bit on myscript.sh:
# chmod u+s myscript.sh
As a consequence, when a user executes the script the resulting process uses George’s user identification rather than the user’s. If set on an executable file, the SUID makes the process inherit the owner’s user identification rather than the one of the user who executed it. This fixes the problem, and even though nobody but George can write directly in mylog.log, anybody can execute myscript.sh which updates the file content.
Similarly, it is possible to set the SGID attribute on an executable file. This makes the process use the owner’s default group instead of the user’s one. This is done by:
# chmod g+s myscript.sh
By setting SUID and SGID attributes the owner makes it possible for other users to execute the file as if they were him or members of his default group.
The SUID and GUID are represented by a “s” which replaces the “x” character respectively in the user and group permissions:
# chmod u+s myscript.sh # ls -l -rwsrwxrwx 10 george administrators 4096 2006-03-10 12:50 myscript.sh # chmod u-s myscript.sh # chmod g+s myscript.sh # ls -l -rwxrwsrwx 10 george administrators 4096 2006-03-10 12:50 myscript.sh
