SUID or Set Owner User ID is a permission bit flag that applies to executables. SUID allows an alternate user to run an executable with the same permissions as the owner of the file instead of the permissions of the alternate user.
Let’s use an example to demonstrate SUID. Suppose that there are three users: KALYANI, SARA and JOHN. Suppose that KALYANI has full root access; that is to say, she can use the sudo command with a valid password. Suppose further that both SARA and JOHN have less or very limited privileges on the machine. Now suppose that we have an executable (ex: su, used to switch users) that belongs to ROOT. Mind you, this is important; it belongs to ROOT, and therefore only ROOT has the permissions to execute it!!!
However, let’s say we assign it SUID. Because we assigned it SUID, that executable, su, is run not as SARA or JOHN but rather as ROOT. Technically, SARA can run her files, and JOHN is allowed to run his files. They aren’t allowed to run files that belong to the root. If they do want to run it, typically, you’ll need to type the sudo command. But here, SARA runs a file that she doesn’t own! And so what we note is that when using SUIDs, the executable is run as the owner of the file, ROOT, and not the person running it (ex: SARA or JOHN).
For example, let’s take the passwd command. The passwd command is used to change a user’s password. Now, if we look at the file in detail, we’ll notice that instead of an x which stands for executing, there will be an “s”. The “s” here stands for SUID. You will further note that the file belongs to ROOT. This technically means that only ROOT has the permission to execute it; however, you will note that everyone can execute the command. As such, with the SUID permissions set, this particular executable can be executed by both SARA and JOHN when it doesn’t actually belong to them! Both SARA and JOHN get the same permissions as ROOT when running this particular executable. This is so even when both SARA and JOHN don’t have root access and don’t have root privileges.
So, in short, because of SUID, both SARA and JOHN will be running the passwd command as if they were its owner, ROOT!
Now suppose for a moment that I remove the SUID from the passwd command. Let’s see what will happen (in the image below).
Now let’s see what will happen when we try to use the passwd command (once SUID has been removed):
As you can see, when I removed the SUID from the passwd command and then tried to execute it as SARA, it refused to execute it. It resulted in an error!
SUID is NOT something to be taken lightly, and as such, one must be very careful when assigning it. In fact, there are special attacks in cybersecurity that aim precisely at executables running on SUID.
In order to find those executables that have an SUID set, we type:
find / -perm -4000 2> /dev/null
# to get all the guids
find / -perm -2000 2> /dev/null
# find all sticky bits
find / -perm -1000 2> /dev/null
Now, we need to learn how to set SUIDs. There are two ways of using chmod: numeric and symbolic.
Using the numeric method:
We use following code to set permissions:
SETGID = 2
STICKY = 1
NONE = 0
READ = 4
WRITE = 2
EXECUTE = 1
During regular permissions, we would write the following:
The latter would imply that we give read, write and execute permissions to the user, the group and others. Now, to use a SUID, we would write the following:
Here, what we have to note is the 4 in the first position. The 4 gives SUID permissions.
Here, it would look like this:
The x for executing will be replaced by an “s”. Now, if the file has not been set to be an executable, then it will be a capital s (“S”). So here we have:
The “s” means that SUID has been set (and the file is executable)!
Using the symbolic method:
The same can be carried out using the symbolic method as well:
Now here, there are times when you might see a capital “S”. The capital “S” means that the file isn’t executable yet.
To revoke the SUID rights, type:
GUID is similar to SUID. In the SUID, the executable in question runs with the privileges of the owner of the file. In the GUID, if it’s an executable, then it runs with the permissions of the group. If it’s a directory, it results in all new files and directories created to belong to the group.
To set the GUID using the numeric method:
Here, the point to note is the 2 (in the first position), which stands for GUID.
To set the GUID using the symbolic method:
However, here, I first see:
Here, there’s a capital “S”. This means that the file is not executable. This can easily be fixed by executing the following code:
Sticky bits apply to directories. When sticky bits are set on a particular directory, any user who has access to the directory and its contents can only delete their own files and cannot touch or delete files belonging to someone else. Sticky bits are typically used when using a shared folder. No one person can delete another’s file within the shared folder even if the permission is 777.
To set sticky bits using the numeric method:
Here, we use the 1 in the first position to denote that it will be a sticky bit.
To set sticky bits using the symbolic method:
Permissions are a crucial part of Linux. The chmod command is typically used to set and modify simple permissions. However, there are special permissions that one can set using the chmod command as well. These special permissions are known as SUID, GUID, and sticky bit. When applied on a particular executable, special permissions run with the permissions of the owner of the file or the group. In other words, it elevates the user’s privileges to that of the owner, typically root, temporarily when using that executable. However, incorrect usage of the special permissions can become a serious threat. In fact, in the field of cybersecurity, it is used as a potential vulnerability to escalate privileges on a machine. So use it wisely and very, very carefully!