Advanced Linux Permissions
The course is part of this learning path
This brief course takes a look at some advanced permissions in Linux, namely the special modes of setuid, setgid, and the sticky bit. This course is part of the Linux Administration Bootcamp learning path, designed to get you up and running with Linux.
- Learn about the special modes of setuid, setgid, and the sticky bit to manage your users and permissions
This course is intended for IT professionals with existing Linux experience who want to learn more about permissions.
This course is intended for people who already know their way around Linux. If you only have a basic knowledge of Linux, then please consider taking our Intermediate Linux Skills course first.
Let's take a couple of minutes to talk about the special modes of setuid, setgid, and the sticky bit. When you start a process it starts running with your user and group permissions. We've talked about ways to run programs as others, including using the Sudo command and the SU command. However, there was a special permission you can use called setuid. It stands for Set User ID, and it forces a process to start as the owner of the file regardless of who executes that file.
To tell if a file has the setuid bit set, you can look at its ls output. You will see an S in the execute field of the owner section of the permissions. The password program is one such file that has the setuid permission. Since the owner of the file is root, when this program gets executed, it runs as the root user. The reason the password command uses setuid root, is because it needs root privileges to modify the Etsy password and or the Etsy shadow files, when a user changes their password.
The ping command is another example of setuid root permissions. The ping command needs a root privileges to access network devices. Setting the setuid bit and having root as the owner of the file, lets anyone on the system successfully use the ping command. The chsh command is yet another example. This command allows the user to change their shell. Doing so requires an update to the Etsy password file which can only be edited by the root user.
Once an attacker gains access to a system they often look for files that are setuid root. Since these files run as root they are an attack surface for privilege escalation attacks. It's important to note that most Linux distributions do not honor setuid on shell scripts, only on binary files. If you were to execute a shell script that has the setuid attributes set, it would execute as you. Set another way, it will execute as the user who runs the script. This is a security measure taken by the OS.
Just like you can determine the numeric permissions to use with chmod by adding together the base 10 values of read, write and execute, you can add together the permissions of setuid, setgid and the sticky bit to get the desired special permissions. The base 10 value of setuid is four, setgid is two, and the sticky bit is one. Just like any other file permissions, you can add the setuid attribute to a file using the chmod command. To do so in symbolic notation run chmod U plus S, and then supply the path to the file.
To add the setuid attribute using octal or numeric notation, start the permissions with a four then follow it with the normal permissions mode. For example, you could run chmod four, seven, five, five to turn on the setuid attribute, allow the owner of the file full permissions, and everyone else the ability to read and execute the file. To remove the setuid permission run chmod U dash S or chmod starting with a zero followed by the desired numeric mode.
To find all the files on the system that have the setuid permission set, you can use the find command. Run find / which means start searching from the root of the file system. Then use the -perm option followed by a / and then 4,000. The forward slash means to match any of the permission bits that are set for the file. If you're using an older version of find, you might need to run -perm plus 4,000. You can also add the -ls option to find which displays the results in a long listing format, so you can view the permissions. What you're looking for is files that can be edited by any other user, other than the owner of that file.
Using a four, seven, five, five mode on a file allows the owner of the file to edit it. Using four, seven, seven, five gives editing permissions to members of the group to which that file belongs. Using four, seven, seven, seven allows anyone to edit the file. This would be extremely bad especially if the file is owned by root. This would allow someone to change the contents of that file to do whatever they want. When they execute that file, it will run with root privileges. This is something that an attacker hopes to find when they gain access to your system. If they broke in with a normal user account they are looking to escalate their privileges to the super user account, so that they can do anything they want with the system.
Setgid is very much like setuid. It causes the program to run with the group privileges of the file rather, than the group privileges of the person executing the file. To tell if a file has the setgid bit set you can look at its ls output. You will see an S in the execute field of the group section of the permissions. One example of a command that has setgid, is the wall command. The wall command displays a message to the terminal of users that are logged into the system. Since all the files that represent a user's terminal are in the TTY group, and the TTY group has write permission on those files, anyone using the wall command is allowed to write to those terminals because that process is running with TTY group privileges.
To find all the files on the system that have the setgid bit permission set, run find/ -perm /2000. Again, the forward slash means to match any of the permission bits that are set for the file. If you are using an older version of find, you might need to use -perm plus 2000. If you wanna get a long ls listing output of all the files that match those permission sets, use the -ls option. To add that setgid permission to a file, use chmod G plus S, or use a two in the first field of the permission string. For example, you could run chmod two, seven, five, five on a file to turn on the setgid attribute. Allow the owner of the file full permissions, and everyone else the ability to read and execute the file.
If you want to add both as setuid and setgid permissions you can run chmod UG plus S, or chmod six followed by the normal permissions. Since setuid is represented by four, and setgid is represented by two, you can add them together to get six and use that in the special permissions field. To remove the setgid permission, use chmod G minus S. You can also subtract two from the special permissions field. To clear all special permissions use chmod zero, followed by the normal desired mode.
Using setgid on a directory causes new files and sub-directories created within it, to inherit the group ID of that directory rather than the group ID of the user creating the new file of a directory. Also, newly created directories inherit the setgid bit. So again, all the new files and directories created within that new directory inherit the group ID of that directory as well. Note that setting the setgid permission on a directory only affects the group ID of new files and sub-directories created after the setgid bit is set.
Adding the setgid bit to an existing directory does not change the permissions of existing files and sub-directories. Using the setgid bit on directories can make it easier when working with groups. If you want to make sure all the files are created with a proper group ownership and a shared location, turn on the setgid bit for that directory. This way you don't have to worry about a user for getting to run the new grep command before creating a file, or forgetting to change the group ownership of a file that they created.
Jason is the founder of the Linux Training Academy as well as the author of "Linux for Beginners" and "Command Line Kung Fu." He has over 20 years of professional Linux experience, having worked for industry leaders such as Hewlett-Packard, Xerox, UPS, FireEye, and Amazon.com. Nothing gives him more satisfaction than knowing he has helped thousands of IT professionals level up their careers through his many books and courses.