How to use suid sgid and sticky bits on linux

This tutorial will help you to under the Sticky bit, SUID and SGID file permissions under Linux system.

What is Sticky Bit?

The sticky bit is used to indicate special permissions for files and directories. If a directory with sticky bit enabled will restrict deletion of the file inside it. It can be removed by the root, owner of the file or who have to write permission on it. This is useful for publically accessible directories like /tmp.

Here is the implementation of Sticky bit on file on Linux system.
Method 1:

Mothod 2:

In above output it showing sticky bit is set with character t or T in permissions filed. Small t represent that execute permission also enable and capital T represent that execute permission are not enabled.

What is SUID (setuid)?

If SUID bit is set on a file and a user executed it. The process will have the same rights as the owner of the file being executed.

For example: passwd command have SUID bit enabled. When a normal user changes his password this script update few system files like /etc/passwd and /etc/shadow which can’t be updated by non-root account. So that passwd command process always run with root user rights.

Here is the implementation of SUID on file under Linux system.

Mehtod 1:

Method 2:

What is SGID (setgid)?

Same as SUID, The process will have the same group rights of the file being executed. If SGID bit is set on any directory, all subdirectories and files created inside will get the same group ownership as the main directory, it doesn’t matter who is creating.

Here is the implementation of SGID on directory on Linux system.

Now swich to other user and create a file in /test directory.

In above example tecadmin.net.txt is created with root group ownership.

Thanks for reading this article, I hope it will help you to understand the sticky bit, SUID, and SGID in Linux.

What are the SUID, SGID and the Sticky Bits?

Sticky Bit

Lets start with Sticky bit first. Since this is the most simplest to explain. Setting the sticky bit tells Unix that once the concerned application is executed, it should remain in memory. Remember that Unix is a multi-user OS and was mainly designed so that multiple users can work simultaneously. Thus the logic used is that a program that exists in memory requires lesser time to start when a new user requests for the same program. Thus when one user has just used a program and then a new user wants to use the same program, the second user doesn’t have to face a time delay for the program to initialize itself. It would be readily available to him. The concept of the sticky bit was a very useful one, long back when fast disk access and other memory access technologies weren’t around. But in today’s age the concept of sticky bit is obsolete, since modern day technology is advanced enough to reduce the time delay while loading applications into the memory. Thus currently the sticky bit is of very little significance. Sticky bit is only associated with executables.

SUID (Set User ID) Bit

Sometime you may faced an error while trying to run any application stating that the application must be ‘SUID root’ . You might have been confused that time, but now once you read this article you would no longer find it confusing.

SUID stands for Set User ID. This means that if the SUID bit is set for any application then your user ID would be set as that of the owner of application/file rather than the current user, while running that application. That means in case I have an application whose owner is ‘ root ‘ and it has its SUID bit set, then when I run this application as a normal user, that application would still run as root. Since the SUID bit tells Linux that the the User ID root is set for this application and whenever this application executes it must execute as if root was executing it (since root owns this file).

SGID (Set Group ID) bit

Just like SUID, setting the SGID bit for a file sets your group ID to the file’s group while the file is executing. IT is really useful in case you have a real multi-user setup where users access each others files. As a single homeuser I haven’t really found a lot of use for SGID. But the basic concept is the same as the SUID, the files whose SGID bit are set would be used as if they belong to that group rather than to that user alone.

Setting the SUID/SGID bits

Setting SUID bits on the file:
Suppose I got the executable called “killprocess” and I need to set the suid bit on this file, go to command prompt and issue command:

Now check permission on the file with command

Observe “s” that has been added for suid bit

Setting GUID bits on the file:
Go to command prompt and issue command:

This will set the GUID bit on the same file, check the permission on this file using command:

Setting Sticky bits on the folder:

Find SUID/SGID files

Find all SUID root files:

Find all SGID root files:

Find all SUID and SGID files owned by anyone:

Special Permissions

Special permissions constitute a fourth permission type in addition to the basic user, group, and other types. As the name implies, these permissions provide additional access-related features over and above what the basic permission types allow. This section details the impact of special permissions, summarized in the table below.

The setuid permission on an executable file means that commands run as the user owning the file, not as the user that ran the command. One example is the passwd command:

In a long listing, you can identify the setuid permissions by a lowercase s where you would normally expect the x (owner execute permissions) to be. If the owner does not have execute permissions, this is replaced by an uppercase S.

The special permission setgid on a directory means that files created in the directory inherit their group ownership from the directory, rather than inheriting it from the creating user. This is commonly used on group collaborative directories to automatically change a file from the default private group to the shared group, or if files in a directory should be always owned by a specific group. An example of this is the /run/log/journal directory:

If setgid is set on an executable file, commands run as the group that owns that file, not as the user that ran the command, in a similar way to setuid works. One example is the locate command:

In a long listing, you can identify the setgid permissions by a lowercase s where you would normally expect the x (group execute permissions) to be. If the group does not have execute permissions, this is replaced by an uppercase S.

Lastly, the sticky bit for a directory sets a special restriction on deletion of files. Only the owner of the file (and root) can delete files within the directory. An example is /tmp:

In a long listing, you can identify the sticky permissions by a lowercase t where you would normally expect the x (other execute permissions) to be. If other does not have execute permissions, this is replaced by an uppercase T.

Setting Special Permissions

– Symbolically: setuid = u+s; setgid = g+s; sticky = o+t
– Numerically (fourth preceding digit): setuid = 4; setgid = 2; sticky = 1

Examples

1. Add the setgid bit on directory:

2. Set the setgid bit and add read/write/execute permissions for user and group, with no access for others, on directory:

by mark · Published 11 February 2015 · Updated 9 January 2018

Sticky Bit, SUID and SGID are special permissions used in Unix-like systems, hence in Linux. Knowing how to use and why one should use them isn’t necessarily fundamental to understand basic permissions in Linux, however they can prove useful in some situations.

Sticky Bit

The first one is the Sticky Bit. Let’s suppose you have a folder where everyone has full permissions, but files that are not important for a user may be important for another one. A user could easily delete a file that is important to another user, and that’s a bit of a problem. That’s what sticky bit is used for: when a sticky bit is used only the owner/root can delete or rename that file. Usually the sticky bit is used on folders. A typical example can be found in /tmp directory

Can you notice that t in the place of the x permission on some lines? That’s the sticky bit. And now how to set the sticky bit: it can be set by using the chmod command:

Notice the 1 in 1777.

Now you’ve probably been wondering if it is “super user id” or “switch user id” or whatever, it actually stands for Set User ID. SUID is a special permissions that allows anyone who executes the program to run it as if he were the owner (it will be loaded with the same permissions).

Let’s take a look at my brand new test file:

Test file has now 777 permissions; let’s apply the SUID:

The x bit of the owner has changed to s: that means SUID is active. But what if it isn’t executable?

The s has changed to S.

Tip: You can set SUID issuing chmod 4777 .

As for SUID it stands for Set Group ID. When SGID is set, whoever will run the program will execute it as if he were in the group of the program.

I restored the test file to 777 without SUID.

Now let’s apply SGID:

The x bit has switched to s, but this time in the group permission: that means SGID is active. And as for the SUID we can disable its execution:

The s has changed to S.

Tip: You can set SGID issuing chmod 2777 .

There are 3 special permission that are available for executable files and directories. These are :

1. SUID permission
2. SGID permission
3. Sticky bit

Set-user Identification (SUID)

Have you ever thought, how a non-root user can change his own password when he does not have write permission to the /etc/shadow file. hmmm… interesting isn’t it? Well to understand the trick check for the permission of /usr/bin/passwd command :

– If you check carefully, you would find the 2 S’s in the permission field. The first s stands for the SUID and the second one stands for SGID.
– When a command or script with SUID bit set is run, its effective UID becomes that of the owner of the file, rather than of the user who is running it.
– Another good example of SUID is the su command :

– The setuid permission displayed as an “s” in the owner’s execute field.

How to set SUID on a file?

Set-group identification (SGID)

SGID permission on executable file

– SGID permission is similar to the SUID permission, only difference is – when the script or command with SGID on is run, it runs as if it were a member of the same group in which the file is a member.

– The setgid permission displays as an “s” in the group’s execute field.

How to set GUID on a file?

SGID on a directory

– When SGID permission is set on a directory, files created in the directory belong to the group of which the directory is a member.
– For example if a user having write permission in the directory creates a file there, that file is a member of the same group as the directory and not the user’s group.
– This is very useful in creating shared directories.

How to set SGID on a directory

Sticky Bit

– The sticky bit is primarily used on shared directories.
– It is useful for shared directories such as /var/tmp and /tmp because users can create files, read and execute files owned by other users, but are not allowed to remove files owned by other users.
– For example if user bob creates a file named /tmp/bob, other user tom can not delete this file even when the /tmp directory has permission of 777. If sticky bit is not set then tom can delete /tmp/bob, as the /tmp/bob file inherits the parent directory permissions.
– root user (Off course!) and owner of the files can remove their own files.

There are two special permissions that can be set on executable files: Set User ID (setuid) and Set Group ID (sgid). These permissions allow the file being executed to be executed with the privileges of the owner or the group. Similarly, there are two special permissions for directories: the sticky bit and the setgid bit. Below are few of the most commonly asked Linux interview questions on the special permissions like SUID, SGID and sticky bit.

What is Set User ID (setuid)?

SUID is a special permission assigned to a file. These permissions allow the file being executed to be executed with the privileges of the owner. For example, if a file was owned by the root user and has the setuid bit set, no matter who executed the file it would always run with root user privileges.

How to set SUID bit on a file?

You must be the owner of the file or the root user to set the setuid bit. Run the following command to set the setuid bit:

View the permissions using the ls -l command:

Note the capital S. This means there are no execute permissions. Run the following command to add execute permissions to the file1 file, noting the lower case s.

Note the lower case s. This means there are execute permissions.

Alternatively, you can set the setuid bit using the numeric method by prepending a 4 to the mode. For example, to set the setuid bit, read, write, and execute permissions for the owner of the file1 file, run the following command:

What is Set Group ID (setgid) for files?

When the Set Group ID bit is set, the executable is run with the authority of the group. For example, if a file was owned by the users’ group, no matter who executed that file it would always run with the authority of the user’s group.

How to set the SGID bit for files?

Run the following command as to set the setgid bit on the file1 file:

Run the following command as root to set the setgid bit, and read, write, and execute permissions for the owner of the file1 file:

The setgid is represented the same as the setuid bit, except in the group section of the permissions:

Use the chmod u+s command to set the setuid bit. Use the chmod g+s command to set the setgid bit.

What is Set Group ID permissions for directories

When the setgid bit is set on a directory, all files created within said directory inherit the group ownership of that directory. For example, the folder1 folder is owned by the user user1, and the group group1:

Files created in the folder1 folder will inherit the group1 group membership:

How to set the SGID bit for directories?

To set the setgid bit on a directory, use the chmod g+s command:

View the permissions using the ls -ld command, noting the s in the group permissions:

Alternatively, prepend a 2 to the directories mode:

What is sticky bit on a directory

When the sticky bit is set on a directory, only the root user, the owner of the directory, and the owner of a file can remove files within said directory.

How to set sticky bit

An example of the sticky bit is the /tmp directory. Use the ls -ld /tmp command to view the permissions:

The t at the end symbolizes that the sticky bit is set. A file created in the /tmp directory can only be removed by its owner, or the root user. For example, run the following command to set the sticky bit on the folder1 folder:

Alternatively, prepend a 1 to the mode of a directory to set the sticky bit:

The permissions should be read, write, and execute for the owner, group, and everyone else, on directories that have the sticky bit set. This allows anyone to cd into the directory and create files.

how to find files with SUID/SGID but set

1. To find all the files with SUID but set, use the below command :

2. Tofind all the files with SGID bit set, use the below command :

You can also combine both the commands to find both SGID and SUID but set files.

This is a quick guide on how to configure and use SGID, SUID and the sticky bit on Linux. I will not get into a lot of details, but I will add comments and notes that might help you understand or overcome a few common issues.

SUID – Set-user Identification

When a command or script with SUID bit set is run, its effective UID becomes that of the owner of the file, rather than of the user who is running it.

Note: SUID does not work on scripts that start with a shebang ( #! )

Note: A capital ’S’ (-rwSr–r–) indicates that the execute bit is not set

SGID – Set-group identification

SGID permission is similar to the SUID permission. The main difference is that when a script or command with SGID set is run, it runs as if it were a member of the same group in which the file is a member.

Setting SGID

Note: A capital ’S’ (-rwxr-Sr–) indicates that the execute bit is not set

Sticky bit

Anyone can write, but only the owner can delete the files (just like /tmp ).

Sticky bit is usually set on directories. Setting the sticky bit on a folder does nothing (on Linux).

Setting sticky bit

Notes:

• A capital ’T’ indicates that the execute bit is not set
• You should give write permission to make sure that the target users can write to the folder

Additional Special Permissions

A . can represent special permissions (SELinux related).

A + indicates ACLs are applied.

Cheat Table

Note: Octal mode is not an absolute translation to symbolic mode as symbolic changes only the specified permission set (user, group OR others), while octal overwrites all permission sets (user, group AND others)

Today we will see how to set Sticky Bit in Linux. This is next to SGID in our ongoing File and Folder permissions series in Linux. We already discussed about CHMOD, UMASK, CHOWN, CHGRP, SGID and SUID file and folder permissions etc in our the previous posts. In this post we will see

• What is Sticky Bit?
• Why we require Sticky Bit?
• Where we are going to implement Sticky Bit?
• How to implement Sticky Bit in Linux?

What is Sticky Bit?

Sticky Bit is mainly used on folders in order to avoid deletion of a folder and it’s content by other users though they having write permissions on the folder contents. If Sticky bit is enabled on a folder, the folder contents are deleted by only owner who created them and the root user. No one else can delete other users data in this folder(Where sticky bit is set). This is a security measure to avoid deletion of critical folders and their content(sub-folders and files), though other users have full permissions.

Learn Sticky Bit with examples:

Example: Create a project(A folder) where people will try to dump files for sharing, but they should not delete the files created by other users.

How can I setup Sticky Bit for a Folder?

Sticky Bit can be set in two ways

1. Symbolic way (t,represents sticky bit)
2. Numerical/octal way (1, Sticky Bit bit as value 1)

Use chmod command to set Sticky Bit on Folder: /opt/dump/

Symbolic way:

Let me explain above command, We are setting Sticky Bit(+t) to folder /opt/dump by using chmod command.

Numerical way:

Here in 1757, 1 indicates Sticky Bit set, 7 for full permissions for owner, 5 for read and execute permissions for group, and full permissions for others.

Checking if a folder is set with Sticky Bit or not?

Use ls -l to check if the x in others permissions field is replaced by t or T

For example: /opt/dump/ listing before and after Sticky Bit set

Before Sticky Bit set:

After Sticky Bit set:

Some FAQ’s related to Sticky Bit:

Now sticky bit is set, let us check if user “temp” can delete this folder which is created xyz user.

if you observe other user is unable to delete the folder /opt/dump. And now content in this folder such as files and folders can be deleted by their respective owners who created them. No one can delete other users data in this folder though they have full permissions.

I am seeing “T” ie Capital s in the file permissions, what’s that?

After setting Sticky Bit to a file/folder, if you see ‘T’ in the file permission area that indicates the file/folder does not have executable permissions for all users on that particular file/folder.

Sticky bit without Executable permissions:

so if you want executable permissions, Apply executable permissions to the file.
chmod o+x /opt/dump/
ls -l
command output:
-rwxr-xrwt 1 xyz xyzgroup 0 Dec 5 11:24 /opt/dump/
Sticky bit with Executable permissions:

you should see a smaller ‘t’ in the executable permission position.

How can I find all the Sticky Bit set files in Linux/Unix.

The above find command will check all the files which is set with Sticky Bit bit(1000).

Can I set Sticky Bit for files?

Yes, but most of the time it’s not required.

How can I remove Sticky Bit bit on a file/folder?

For instance, when a regular user needs to change their password which exists in the /etc/shadow file, they will need the permissions of “root” to change their password as /etc/shadow is owned by “root” and no one else has permissions to write to it. This is resolved by setting the SUID bit, which gives the user the permissions of root while using /etc/shadow.

If we look at the /etc/passwd, we see its permissions as below.

Note that where we would expect an x in the first stanza of permissions (the owner’s) there is an s. This s indicates that the sticky, or special, bit is set. This means that when this file is accessed by someone other than root, they have root’s permissions while they are running or using it.

Exploiting the SUID Bit

Imagine, if you will, a scenario where I run a program that has the SUID bit set and has root privileges momentarily, I can re-engineer it to do something other than what it was designed to do. For instance, accessing the /etc/shadow file. If I can get it to do my bidding—even for just a moment—while my permissions are root’s, I can own the system.

Elevating Privileges

This SUID bit can, at times, be exploited to elevate privileges once we have hacked a system, have only a terminal, and have only regular user permissions. Also, if we are a local user and want to elevate our privileges, we can look to exploit applications that have the SUID or SGID bit set. If we can find an app that uses root permissions to run, we may be able to manipulate it to give us its elevated status—even if for a moment.

A good example of such a hack was the old eFax program that installed by default on nearly every KDE Linux system. The program was set up to to use root privileges in order to send faxes from your computer. It was possible to use these privileges of the eFax program to access the /etc/shadow file and print out the entire contents. Of course, once it grabbed the/etc/shadow file, it was just a matter of cracking the hashes (most importantly the root user hash) to take total control of the system.

What I want to do here is show you how you can find these binaries, programs, and apps on your Linux, Mac or Unix system that have root privileges, if even for only a moment, and may be able to be manipulated to elevate your privileges when you only have limited user privileges.

Step 1 Finding Files with the SUID Bit Set

The “find” command in Linux is powerful utility that enables us to find files that meet some specified criteria. In this case, we want the find command to search the entire file system to locate files that have permissions with the SUID bit set, that are owned by root. We can accomplish by typing the following command:

Let’s break this command down to its individual parts.

• / says start at the top (root) of the file system and search every directory
• -perm says look for the permissions that follow
• +4000 is the numerical representation of the SUID bit permission
• -user says look for files that are owned by the following user
• root is the user whose files we are looking for
• -type defines the type of file we are looking for
• f represents a regular file (not directories or special files)
• -print tells the command to print to standard out the path to the file

When we run this command against a Debian 7 GNOME system, we get the following results.

As you can see, most of what was returned are BASH commands and other tried-and-true applications. Since these commands and applications have been tested over years, you are unlikely to find the vulnerabilities you need. What we are looking for are new untried and untested applications that might have the sticky bit set and may have been carelessly coded.

Step 2 Looking for SGID Bit Set

Now, let’s look for programs that have the SGID bit set. We can find then by using the following command.

• debian > find / -perm +2000 -user root -type f -print

The only difference here is that instead of looking for +4000 permissions as in Step #1, now we are looking for +2000 permissions (SGID).

When we run this command on the Debian 7 system, we get the following output.

I have highlighted numerous games that were returned from this search. This means that these games run with the permissions of the root group permissions. These might be a fertile group to seek to manipulate for privilege escalation as many games are poorly coded and might be good candidates to manipulate to gain root privileges.

I will continue to provide you the tools and techniques to hack with the best hackers in the world, so keep coming back, my nascent hackers.