قالب وردپرس درنا توس
Home / Tips and Tricks / Use SUID, SGID and Sticky Bits on Linux

Use SUID, SGID and Sticky Bits on Linux



  A terminal window on a Linux system.
Fatmawati Achmad Zaenuri / Shutterstock

SUID, SGID and Sticky Bits are powerful special permissions that you can set for executable files and folders on Linux. We share the benefits ̵

1; and potential pitfalls – of using them.

They are already in use.

Building security into a multi-user operating system has several problems. Take, for example, the (apparent) basic concept of passwords. They must all be saved so that every time someone logs in, the system can compare the password that they type with the saved copy. Since passwords are the keys of the kingdom, they must of course be protected.

Under Linux, saved passwords are protected in two ways: they are encrypted and only someone with root has access to the file containing the passwords. That may sound good, but it poses a dilemma: if only people with root have access to saved passwords, how can those who don't have access change their passwords?

Increase your status [19659005] Usually, Linux commands and programs are executed with the same set of permissions as the person who starts the program. When root executes the command passwd to change a password, it is executed with the permissions of root . That means that the command passwd has free access to the saved passwords in the file / etc / shadow .

What would be ideal is a scheme in which everyone on the system maintains the passwd program, but lets the passwd program retain the elevated rights of root . This would allow anyone to change her own password.

The above scenario is exactly what the Set User ID bit ( SUID ) does. It executes programs & commands with the permissions of the file owner, rather than the permissions of the person starting the program.

You are increasing the status of the program.

However, there is another problem. The person must be prevented from interfering with someone else's password. Linux includes the SUID scheme that allows it to run applications with a number of temporarily borrowed permissions – but that's only half the security story.

The operating mechanism that prevents someone from working with another person's password is contained in the program passwd not the operating system and the SUID scheme.

Programs that run with elevated privileges can present security risks if they are not created with a "security by design" spirit. That means that security is the first thing you consider, and then you build on it. Do not write your program and then try to give it a layer of security.

The biggest advantage of open source software is that you can look at the source code yourself or refer to trusted peer reviews. The source code of the program passwd contains checks so that you can see if the person who runs the program is root . Various options are allowed if someone is root (or someone who uses sudo ).

This is the code that detects whether someone is root .

 A source code fragment from

The following is an example that has been taken into account. Because root can change any password, the program does not have to deal with the checks it usually performs to see which passwords the person with permission has changed. So for root it skips those checks and leaves the checking function.

 A source code fragment from

With the Linux core commands and utilities, you can be confident that they have security embedded and that the code has been revised many times. Of course there is always the threat of unknown exploits. However, patches or updates appear quickly to fix newly identified vulnerabilities.

It is third-party software – especially non-source software – you must be extremely careful when using SUID with. We don't say you shouldn't do it, but if you do, you want to make sure it doesn't expose your system to risks. You do not want to increase the rights of a program that will not control itself and the person running it correctly.

Linux commands that use SUID

The following are some Linux commands that use the SUID bit to give the command elevated privileges when executed by a regular user:

  ls -l / bin / su 
  ls -l / bin / ping 
  ls -l / bin / mount 
  ls -l / bin / umount 
  ls -l / usr / bin / passwd 

  A list of Linux commands whose SUID bit is set in a terminal window.

Note that the file names are highlighted in red, indicating that the SUID bit is set.

The permissions for a file or folder are usually represented by three groups of three characters: rwx. These stand for reading, writing and execution. If the letters are present, permission has been granted. However, if there is a hyphen ( - ) instead of a letter, that permission is not given.

There are three groups of these permissions (from left to right): those for the owner of the file, for members of the file group, and for others. When the bit SUID is set to a file, an "s" stands for the owner's execution permission.

If the bit SUID is set to a file that has no executable file capability, a capital letter "S" indicates this.

We will view an example. Regular user dave types the command passwd :

  passwd 

  The

The passwd command prompts dave for his new password. We can use the command ps to view the details of active processes.

We use ps with grep in another terminal window and search for the passwd process. We will also use the options -e (any process) and -f (full format) with ps .

We type the following command:

  ps -e -f | grep passwd 

  The

Two lines are reported, the second is the grep process looking for commands with the string "passwd" in it. However, it is the first rule that interests us, because that is the one for the passwd process dave launched.

We can see that the passwd process executes the process the same as it would be if root had launched it.

Setting the SUID bit

It is easy to change the SUID bit with chmod . The symbolic mode u + s sets the bit SUID and the symbolic mode us erases the bit SUID .

To illustrate the concepts of the SUID bit, we have made a small program with the name htg . It is in the user's root directory dave and the bit SUID is not set. When it is executed, the real and effective user ID & # 39; s (UID) is displayed.

The real UID is from the person who started the program. The effective ID is the account with which the program behaves as if it had been launched by.

We type the following:

  ls -lh htg 
  ./ htg 

  The

When we run the local copy of the program, we see that the real and effective ID & Both are set to dave . So it behaves exactly like a normal program should do.

Let's copy it to the / usr / local / bin folder for others to use.

We type the following using chmod to set the bit SUID and then check if it is set:

  sudo cp htg / usr / local / bin 
  sudo chmod u + s / usr / local / bin / htg 
  ls -hl / usr / local / bin / htg 

  The

So the program is copied and the SUID bit is set. We will perform it again, but this time we will execute the copy in the folder / usr / local / bin :

  htg 

  The

Although dave launched the program, the effective ID is set to the user root . So when mary starts the program, the same thing happens as shown below:

  htg 

  The

The real ID is mary and the effective ID is root . The program runs with the root user's permissions.

RELATED: How to use the chmod command on Linux

The SGID Bit

The Set Group ID ( SGID ) bit seems very on the bit SUID . When the bit SGID is set to an executable file, the effective group is set to the group of the file. The process runs with the permissions of the members of the file group, rather than the permissions of the person who started it.

We have adjusted our program htg to also show the effective group. We will change the program group htg to user mary 's default group, mary . We also use the symbolic modes us and g + s with chown to remove the bit SUID and to enter the set SGID .

To do this, we type the following:

  sudo chown root: mary / usr / local / bin / htg 
  sudo chmod us, g + s / usr / local / bin / htg 
  ls -lh / usr / local / bin / htg 

  The

You can see the bit SGID that is indicated by the "s" in the group permissions. Also note that the group is set to mary and the file name is now highlighted in yellow.

Before we execute the program, we will determine which groups dave and mary belong to. We use the id command with the -G (groups) option to print all group IDs. Then we run the program htg as dave .

We type the following commands:

  id -G dave 
  id -G mary 
  htg 

  Het

The ID of the default group for mary is 1001 and the effective group of the program htg is 1001. So although it was launched by dave it runs with the permissions of members in the mary group. It is the same as if dave had become a member of the mary group.

Let's apply the SGID bit to a folder. First we create a folder with the name & # 39; work & # 39; and we change the group to & # 39; geek & # 39 ;. Next, we set the bit SGID in the folder.

When we use ls to check the settings of the folder, we also use the -d (directory) option to see the details of the directory, not the content of it.

We type the following commands:

  sudo mkdir work 
  sudo chown dave: geek work 
  sudo chmod g + s work 
  ls -lh -d work 

  The [19659006] The SGID bit and "geek" group are set. These affect all items created in the work folder .

We type the following to open the work folder, create a folder named & # 39; demo & # 39; and check its properties: [19659024] cd-work

  mkdir demo 
  ls -lh -d demo 

  The

The SGID bit and the "nerd" group are automatically applied to the "demo" directory.

Type the following to create a file with the command touch and check its properties:

  touch usable.sh 
  ls -lh useful.sh 

  The

The group of the new file is automatically set to & # 39; geek & # 39 ;.

RELATED: How to use the chown command on Linux

The Sticky Bit [19659005] The sticky bit owes its name to its historical purpose. When set to an executable file, it marked to the operating system that the text portions of the executable file had to be kept in swap, making the reuse faster. In Linux, the sticky bit only affects a folder – it would not make sense to place it in a file.

When you set the sticky bit in a folder, people can only delete files that belong to that folder. They cannot delete files that belong to someone else, regardless of which combination of file permissions are set on the files.

Allows you to create a folder that everyone – and the processes they start – to use as shared file storage. The files are protected, because again, nobody can delete someone else's files.

Let's create a folder with the name & # 39; shared & # 39 ;. We use the symbolic mode o + t with chmod to set the sticky bit in that folder. We look at the permissions in that folder, as well as the folders / tmp and / var / tmp .

We type the following commands:

  mkdir shared 
  sudo chmod o + t shared 
  ls -lh -d shared 
  ls -lh -d / tmp 
  ls -lh -d / var / tmp 

  The [19659006] If the sticky bit is set, the executable bit of the "other" set of file permissions is set to "t". The file name is also marked in blue.

The / tmp and / var / tmp folders are two examples of folders with all file permissions set for the owner, group, and others (therefore, they are highlighted in green). They are used as shared locations for temporary files.

Anyone should be able to do anything in theory with those permissions. However, the sticky part replaces them, and no one can delete a file that is not his.

Memories

Below is a short checklist of what we have discussed above for future reference:

  • SUID only works on files.
  • You can apply SGID to folders and files.
  • You can only apply the sticky bit to folders.
  • If the " s ", " g " or " t " indicators are shown in capital letters, the executable bit ( x ) is not set.




Source link