When you run an executable file in Linux, it usually runs with the current user and group ID. However, there are times when you need to run that file as another user (like root). Instead of switching your user account, you can make use of setuid to run the executable as the file owner and not the current user. Here we will explain how setuid works and how it allows users to run executables/binaries with escalated privileges.
How setuid Works?
Setuid stands for SET User ID on execution. Let’s say we have an executable called “identity” created by the root user. When you run it, it will run with your user ID, group ID and user privileges. If the setuid bit is set on the “identity” file, when you run it, it will be run as the root user and its user privileges.
As an illustration, we can check the ownership of the “identity” file first and verify that it is owned by the root user. The permission string also shows the executable (x) bits set for the user, group and others.
User “john1” executes the “identity” file, which becomes a process on execution. As shown in the process list, the process is created and run under the “john1” username and user ID.
Next, as a root user, we set the setuid bit of the “identity” file:
“u” denotes that setuid bit (+s) must be set only for the user.
For the owner, in the executable part of the permission string we can see that “x” has been replaced with “s.” Whenever you encounter “s” for an executable, it means the setuid bit has been set on it.
The numerical variant of the
chmod command can also be used as shown below.
The addition of 4 in the numerical permission string denotes inclusion of the setuid bit.
The following is what happens when “john1” executes the “identity” file again. Looking at the list of running processes, we can now see that the process is created and run by the “root” user instead of “john1.”
Important use of the setuid bit
Most of the time you will hear from experts that you shouldn’t run applications as the root user. However, there are instances where certain files need to run with root permission. For example, the
passwd utility that comes installed by default on Linux systems has the setuid bit set on it.
The reason is simple: Password information for a user is stored in “/etc/passwd” and “/etc/shadow” files, which can only be modified by “root.” When “john1” attempts to change the password for himself, he will need to have the permission to modify information in the two aforementioned files. Having the setuid bit set on
passwd enables “john1” to temporarily have root permissions to change the user password and also update information in the two files.
Setuid Security Risk
If you are not careful, an attacker can exploit setuid binaries to control your system. Users normally should not have setuid programs installed, especially setuid to users other than themselves. Most importantly, you should not have any setuid enabled binary for the root user in your Home folder. These are usually Trojan Horses, or malware.
Setuid can only be set on executable files. Likewise, the
setgid bit can be set too, which enables all members of a group to run an executable with owner permissions.
Do note that
setgid bits are security-sensitive and must be used by qualified system administrators only.