SUID, SGID and Sticky Bits are powerful special permissions that you can set for executables and directories on Linux. We will share the benefits and potential pitfalls of using them.
They are already used
Integrating security into a multi-user operating system poses several problems. Take the basic concept (apparently) of passwords, for example. They must all be stored so that each time someone logs in, the system can compare the password they type to the stored copy. Obviously, since passwords are the keys to the kingdom, they must be protected.
On Linux, stored passwords are protected in two ways: they are encrypted, and only someone with root privileges can access the file containing the passwords. This may sound correct, but it poses a dilemma: if only people with root privileges can access stored passwords, how can those who do not have this access change their passwords?
Raise your status
Usually Linux commands and programs run with the same set of permissions as the person launching the program. When root runs the passwd command change a password, it runs with root permissions. This means that the passwd command can freely access passwords stored in the / etc / shadow file.
Ideally, this would be a scheme in which anyone on the system could run the passwd program, but have the passwd program keep elevated root privileges. This would allow anyone to change their own password.
The above scenario is precisely what the Set User ID (SUID) bit does. he execute programs and commands with the permissions of the file owner, rather than the permissions of the person launching the program.
You improve the program status
There is, however, another dilemma. The person should be prevented from meddling in someone else’s password. Linux incorporates the SUID scheme which allows it to run applications with a set of temporarily borrowed permissions, but this is only half the story of security.
The control mechanism that prevents someone from working with another person’s password is contained in the passwd program, not in the operating system and the SUID scheme.
Programs that run with high privileges can pose security risks if they are not created with a “security by design” mindset. This means that safety is the first thing you consider, and then you get inspired by it. Do not write your program, then try to give it a layer of security afterwards.
The biggest advantage of open source software is you can watch the source code yourself or refer to trusted peer reviews. In the source code of the passwd program there are checks, so you can see if the person running the program is root. Different capacities are allowed if someone is root (or someone who uses sudo).
This is the code that detects if someone is root.
Here is an example in which this is taken into account. Since root can change any password, the program doesn’t have to worry about the checks it usually does to see which passwords the person has permission to change. So for root, it skip these checks and exit the check function.
With basic Linux commands and utilities, you can be sure that they are secure and that the code has been revised several times. Of course, there is always the threat of still unknown exploits. However, patches or updates appear quickly to address any newly identified vulnerabilities.
These are third-party software, especially those that are not open source; you should be extremely careful with using SUID with them. We’re not saying you don’t, but if you do, you want to make sure it won’t put your system at risk. You don’t want to elevate the privileges of a program that is not going to self-govern properly and the person who runs it.
Linux commands that use SUID
Here are some of the Linux commands that use the SUID bit to grant the command elevated privileges when executed by a normal user:
ls -l / bin / su
ls -l / bin / ping
ls -l / bin / mount
ls -l / bin / umount
ls -l / usr / bin / passwd
Note that the file names are highlighted in red, which indicates that the SUID bit is set.
Permissions on a file or directory are generally represented by three groups of three characters: rwx. These mean read, write and perform. If letters are present, this authorization has been granted. If a hyphen (-) instead of a letter is present, however, this permission has not been granted.
There are three groups of these permissions (from left to right): those for the file owner, for members of the file group, and others. When the SUID bit is set on a file, an “s” represents the owner’s authorization to execute.
If the SUID bit is set to a file that has no executable capabilities, an uppercase “S” indicates this.
We will see an example. The regular dave user types the passwd command:
The passwd command prompts dave to enter its new password. We can use the ps command to see details of running processes.
We will use ps with grep in a different terminal window and find the passwd process. We will also use the options -e (all processes) and -f (full format) with ps.
We type the following command:
ps -e -f | grep passwd
Two lines are reported, the second being the grep process looking for commands containing the string “passwd”. This is the first line that interests us, because it is the one that the passwd process launched.
We can see that the passwd process runs in the same way as if root had started it.
Definition of the SUID bit
It is easy to change the SUID bit with chmod. Symbolic mode u + s sets the SUID bit and symbolic mode u-s clears the SUID bit.
To illustrate some of the concepts of the SUID bit, we have created a small program called htg. It is located in the root directory of the user dave and the SUID bit is not set. When run, it displays real and effective user IDs (UID).
The truth UID belongs to the person who started the program. The effective ID is the account by which the program behaves as if it had been launched by.
We type the following:
ls -lh htg
When we run the local copy of the program, we see that the actual and effective IDs are both set to dave. So it behaves like a normal program.
Let’s copy it to the / usr / local / bin directory so that others can use it.
We type the following, using chmod to set the SUID bit, and then verify that it has been set:
sudo cp htg / usr / local / bin
sudo chmod u + s / usr / local / bin / htg
ls -hl / usr / local / bin / htg
Thus, the program is copied and the SUID bit is set. We will run it again, but this time we will run the copy in the / usr / local / bin folder:
Even if dave started the program, the effective ID is set to the root user. So if Mary launches the program, the same thing happens, as shown below:
The actual ID is mary and the effective ID is root. The program runs with the permissions of the root user.
The SGID bit
The Set Group ID (SGID) bit is very similar to the SUID bit. When the SGID bit is set to an executable file, the effective group is set to the file group. The process runs with the permissions of the group members of the file, rather than the permissions of the person who launched it.
We have modified our htg program to also show effective grouping. We are going to change the group of the htg program to be the default group of the user mary, mary. We will also use the symbolic modes u-s and g + s with chown to remove the SUID bit and set the SGID.
To do this, we type the following:
sudo chown root: mary / usr / local / bin / htg
sudo chmod u-s, g + s / usr / local / bin / htg
ls -lh / usr / local / bin / htg
You can see the SGID bit indicated by the “s” in group permissions. Also note that the group is set to mary and the file name is now highlighted in yellow.
Before running the program, let’s determine which dave and mary groups belong to. We will use the id command with the -G (groups) option, to print all group IDs. Then we will run the htg program as dave.
We type the following commands:
id -G dave
id -G mary
The default group ID for mary is 1001, and the effective group for the htg program is 1001. So, although it was started by dave, it works with permissions from members of the group mary. It’s the same as if Dave had joined the Mary group.
Let’s apply the SGID bit to a directory. First, let’s create a directory called “work”, then change its group to “geek”. We will then set the SGID bit on the directory.
When we use ls to check directory settings, we also use the -d (directory) option so that we can see the details of the directory, not its contents.
We type the following commands:
sudo mkdir work
sudo chown dave: geek job
sudo chmod g + s work
ls -lh -d work
The SGID bit and the “geek” group are defined. These will affect all items created in the working directory.
We type the following to enter the working directory, create a directory called “demo” and check its properties:
Demo ls -lh -d
The SGID bit and the “geek” group are automatically applied to the “demo” directory.
Let’s type the following to create a file with the to touch order and check its properties:
ls -lh useful.sh
The group of the new file is automatically set to “geek”.
The Sticky Bit
The sticky bit takes its name from its historical goal. When defined on an executable, it signals to the operating system that the text parts of the executable must be kept in to exchange, which accelerates their reuse. Under Linux, the sticky bit affects only one directory – placing it on a file would make no sense.
When you set the sticky bit on a directory, users can only delete the files that belong to them in that directory. They cannot delete files belonging to someone else, regardless of the combination of file permissions set on the files.
This allows you to create a directory that everyone and the processes they launch can use as shared file storage. The files are protected because, again, no one can delete someone else’s files.
Let’s create a directory called “shared”. We will use the symbolic mode o + t with chmod to define the sticky bit on this directory. We will then examine the permissions on this directory, as well as the / tmp and / var / tmp directories.
We type the following commands:
sudo chmod o + t shared
ls -lh -d shared
ls -lh -d / tmp
ls -lh -d / var / tmp
If the sticky bit is set, the executable bit for “the other” set of file permissions is set to “t”. The file name is also highlighted in blue.
The / tmp and / var / tmp folders are two examples of directories with all file permissions set for the owner, group, and others (which is why they are highlighted in green). They are used as shared locations for temporary files.
With these permissions, anyone should theoretically be able to do anything. However, the sticky bit replaces them, and no one can delete a file that does not belong to them.
The following is a quick checklist of what we have covered above for future reference:
SUID works only on files.
You can apply SGID to directories and files.
You can only apply the sticky bit to directories.
If the flags “s”, “g” or “t” appear in upper case, the executable bit (x) has not been set.