A detailed explanation of the usage of special permissions for SetUID (SUID) files
1 Introduction
[root@localhost ~]# ls -l /usr/bin/passwd -rwsr-xr-x. 1 root root 22984 Jan 7 2007 /usr/bin/passwd
It can be seen that the x permission bit originally represents the permission of the file owner, but the s permission appears. This permission is usually called ， SetUID, or ， SUID special permission for short.
2. Functional interpretation
SUID special permission is only applicable to executable files. Its function is that as long as the user has execution permission on the file with SUID, when the user executes the file, he will execute the file as the file owner. Once the file execution is completed, the identity switching will disappear.
For example, we all know that the password data of all users in the Linux system are recorded in the file / etc/shadow. You can see from the command ll /etc/shadow that the permission of this file is 0 (- ---------), that is, ordinary users do not have any operation permission on this file.
Why can ordinary users use the passwd command to change their passwords?
From the permission configuration of the passwd command, you can see that this command has SUID special permission, and other people also have execution permission for this file, which means that any user can execute the passwd command as the file owner, that is, root. In Linux system, the file owner of most commands is root by default.
In other words, when ordinary users use the passwd command to try to change their password, they are actually executing the passwd command as root. Just because root can write the password to the / etc/shadow file, ordinary users can do the same. However, once the command is executed, the root identity of ordinary users will disappear.
# Manually remove the SUID permission from the / usr/bin/passwd file [root@localhost ~]# chmod u-s /usr/bin/passwd #Owner cancels SetUID permission [root@localhost ~]# ll /usr/bin/passwd -rwxr-xr-x. 1 root root 30768 Feb 22 2012 /usr/bin/passwd [root@localhost ~]# su - lamp [lamp@localhost ~]$ passwd Changing password for user lamp. Changing password for user. (current) UNIX password: #There seems to be no problem New passwor: Retype new password: password:Authentication token manipulation error <--Authentication token operation error #The last password did not take effect #Obviously, although the user has the permission to execute the passwd command, he does not have the permission to modify the / etc/shadow file, so the final password modification failed. # Note that after the experiment is completed, be sure to add the SetUID permission of / usr/bin/passwd file.
Can't ordinary users use the cat command to view the / etc/shadow file. Because cat does not have SUID permission, when executing cat /etc/shadow command, ordinary users cannot be as root, but only as ordinary users, so they cannot read successfully.
From this, we can conclude that SUID special permission has the following characteristics:
- Only executable files can set SetUID permission. Setting SUID for directory is invalid.
- The user should have x (execute) permission on the file.
- The user executes the file as the owner of the file.
- SetUID permission is only valid during file execution. Once the execution is completed, the identity switching will disappear.
3. Do not set SetUID (SUID) permission easily, otherwise it will bring major security risks
Attempt to give Vim SetUID permission
[root@localhost ~]# chmod u+s /usr/bin/vim [root@localhost ~]# ll /usr/bin/vim -rwsr-xr-x. 1 root root 1847752 Apr 5 2012 /usr/bin/vim
At this time, it will be found that even if ordinary users use the vim command, they will temporarily obtain the identity and permission of root. For example, many files that ordinary users cannot view and modify can be viewed. Taking / etc/passwd and / etc/shadow files as examples, ordinary users can manually modify their UID to 0, which means that, This user has been upgraded to super user. In addition, ordinary users can also modify important system files such as / etc/inittab and / etc/fstab, which can easily paralyze the system.
In fact, if any command that can be executed only by the administrator is given SetUID permission, the consequences will be disastrous. Ordinary users can restart the server at any time, close unpleasant services at any time, and add other ordinary users' servers at any time. You can imagine what it looks like. Therefore, SetUID permissions cannot be set arbitrarily.
To prevent others (such as hackers) from maliciously tampering with SetUID permissions, here are the following suggestions:
-
The write permission of key directories should be strictly controlled, such as "/" and "/ usr".
-
The password setting of users shall strictly comply with the password specification.
-
Make a list of files in the system that should have SetUID permission by default, and regularly check whether files outside the list are set with SetUID permission.
The first two points will not be explained too much. Here is the last point to provide you with a script for reference only.
First, after the first installation of the server, immediately find all the files with SetUID and SetGID permissions in the system and record them as the reference template for scanning. If the result of a scan is inconsistent with the template saved this time, it indicates that SetUID and SetGID permissions have been modified.
Note: unless in special circumstances, do not manually modify SetUID and SetGID permissions, which is very unsafe. And even if we do experiments to modify SetUID and SetGID permissions, we should modify them immediately to avoid potential security risks.
[root@localhost ~]# find / -perm -4000 -o -perm -2000 > /root/suid.list
#-perm installation permission check- 4000 corresponds to SetUID permission, and - 2000 corresponds to SetGID permission
#-o means logic or "or". And put the results of the command search in / root / suid List file
Next, just scan the system regularly and compare it with the template file. The script is as follows:
[root@localhost ~]#vi suidcheck.sh
#!/bin/bash
find / -perm -4000 -o -perm -2000 > /tmp/setuid.check
#Search all files with SetUID and SetGID permissions in the system and save them to a temporary directory
for i in $(cat /tmp/setuid.check)
#Loop. Each loop takes out the file name in the temporary file
do
grep $i /root/suid.list > /dev/null
#Check whether the file name is in the template file
if ["$?"!="o"]
#Detect the return value of the previous command. If it is not 0, it proves that the previous command reported an error
then
echo "$i isn't in listfile! " >>/root/suid_log_$(date +%F)
#If the file name is not in the template file, an error message is output and the error message is written to the log
fi
done
rm -rf/tmp/setuid.check
#Delete temporary file
[root@localhost ~]# chmod u+s /bin/vi
#Manually add SetUID permission to vi
[root@localhost ~]# ./suidcheck.sh
#Execute detection script
[root@localhost ~]# cat suid_log_2013-01-20
/bin/vi isn't in listfile!
#An error is reported. vi is not in the template file. On behalf of vi, the SetUID permission has been modifiedThe key to the success of this script is whether the template file is normal. Therefore, we must establish the template file immediately after installing the system and ensure the security of the template file.
II. Detailed explanation of special permission usage of SetGID (SGID) file
1. Introduction
When the s permission is in the x permission bit of the group to which it belongs, it is called "SGID" special permission for short.
[root@localhost ~]# ll /usr/bin/locate -rwx--s--x. 1 root slocate 35612 8 June 24, 2010 /usr/bin/locate
Unlike SUID, SGID can configure both files and directories.
2. Functional interpretation
(1) Effect on documents
Similar to SUID, SGID has the following characteristics for files:
- SGID is only valid for executable files. In other words, only executable files can be given SGID permission. It is meaningless to give SGID to ordinary files.
- The user needs to have x permission for this executable file;
- When a user executes an executable file with SGID permission, the user's group identity will change to the group to which the file belongs;
- SGID permission gives users the effect of changing group identity, which is only valid during the operation of executable files;
In fact, the difference between SGID and SUID is that SUID gives the user the permission of the file owner, while SGID gives the user the permission of the group to which the file belongs
Taking the locate command as an example, you can see that the / usr/bin/locate file is given the special permission of SGID, which means that when an ordinary user uses the locate command, the user's group will directly become the group of the locate command, that is, slocate. The locate command is used to find qualified files by file name in the system. When performing a search operation, it will search / var / lib / mlocate / mlocate DB find the answer from the data in this database, and view the permissions of this database:
[root@localhost ~]# ll /var/lib/mlocate/mlocate.db -rw-r-----. 1 root slocate 1838850 1 April 20:29 /var/lib/mlocate/mlocate.db
As you can see, mlocate The group of the DB file is slocate. Although you only have r permission on the file, it is enough for ordinary users to execute the locate command. On the one hand, ordinary users have the permission to execute the locate command. Secondly, the locate command has the SGID permission, which makes the group identity of ordinary users change to slocate when executing the locate command, while slocate has the permission to mlocate The DB database file has r permission, so even ordinary users can successfully execute the locate command.
Again, whether SUID or SGID, their conversion of user identity is only effective during the execution of the command. Once the command is executed, the identity conversion will also fail.
(2) Effect on Directory
SGID can also work on directories, and this usage is common.
When a directory is given SGID permission, the effective group of ordinary users entering the directory will become the group to which the directory belongs. When creating a file (or directory), the group to which the file (or directory) belongs will no longer be the user's group, but the group to which the directory belongs.
In other words, only when ordinary users have rwx permissions on the directory with SGID permission can the function of SGID be brought into full play. For example, if the user has only rx permission on the directory, after entering the directory, although its effective group becomes the group to which the directory belongs, without x permission, the user cannot create files or directories in the directory, and SGID permission cannot play its role.
[root@localhost ~]# cd /tmp #Enter the temporary directory to do this experiment. Because only temporary directories can be modified by ordinary users [root@localhost tmp]# mkdir dtest #Create test directory [root@localhost tmp]# chmod g+s dtest #Give SetGID permission to the test directory [root@localhost tmp]# ll -d dtest drwxr-sr-x 2 root root 4096 Apr 19 06:04 dtest #SetGID permission is already in effect [root@localhost tmp]# chmod 777 dtest #Give 777 permission to the test directory so that ordinary users can write [root@localhost tmp]# su - lamp [lamp@localhost ~]# grep lamp /etc/passwd /etc/group /etc/passwd:lamp:x:501:501::/home/lamp:/bin/bash /etc/group:lamp:x:501: #Switch to ordinary user lamp. The group of this user is lamp [lamp@localhost ~]$ cd /tmp/dtest/ #Ordinary users enter the test directory [lamp@localhost dtest]$ touch abc [lamp@localhost dtest]$ mkdir zimulu #Create a new file abc and subdirectory zimulu in this directory [lamp@localhost dtest]$ ll total 0 -rw-rw-r--. 1 lamp root 0 Apr 19 06:07 abc drwxrwsr-x. 2 lamp root 40 Apr 19 06:07 zimulu # You can see that although it is the abc file and zimulu directory created by the lamp user, # However, the group to which they belong is not lamp (the group to which the lamp user belongs), but root (the group to which the dtest directory belongs).
III. detailed explanation of special permission usage of Stick BIT (SBIT) file
1. Introduction
Sticky BIT, abbreviated as SBIT special permission, can mean adhesive bit, Sticky BIT, anti deletion bit, etc.
The SBIT permission is only valid for the directory. Once the SBIT permission is set for the directory, only yourself and root have the right to modify or delete the file or directory created by the user in this directory.
That is, when user a enters directory a as the group or other person to which the directory belongs, if Party A has w permission to the directory, it means that Party A can modify or even delete any file or subdirectory created by any user in directory a. However, if directory a is set with SBIT permission, user a can only operate the files or directories created by himself, but cannot modify or even delete the files or directories created by other users.
# In Linux system, the / tmp directory where temporary files are stored is set with SBIT permission [root@localhost ~]# ll -d /tmp drwxrwxrwt. 4 root root 4096 Apr 19 06:17 /tmp # In the permission setting of other person's identity, the original x permission bit is occupied by t permission, which means that this directory has SBIT permission [root@localhost ~]# useradd lamp [root@localhost ~]# useradd lamp1 #Establish the test user lamp and lamp1, and omit the password setting process [root@localhost ~]# su -lamp #Switch to lamp user [lamp@localhost ~]$ cd /tmp [lamp@localhost tmp]$ touch ftest #Establish test file [lamp@localhost tmp]$ll ftest -rw-rw-r-- 1 lamp lamp Apr 19 06:36 ftest [lamp@localhost tmp]$ su - lamp1 #Omit the process of inputting lamp1 user password and switch to lamp1 user [lamp1 @localhost ~]$ cd /tmp/ [lamp1 @localhost tmp]$ rm -rf ftest rm:cannot remove 'ftest':Operation not permitted # Although the permission setting of / tmp directory is 777, because it has SBIT permission, the file ftest created by lamp user in this directory and lamp1 user failed to delete.
IV. detailed explanation of the setting of special file permissions (SUID, SGID and SBIT)
Rely on the chmod command. There are two ways to use the chmod command to set permissions for a file or directory: numeric and alphabetic. SUID, SGID and SBIT special permissions can also be set for a file or directory.
1 digital form
#Digital form [root@localhost ~]# chmod 755 ftest #Alphabetic form [root@localhost ~]# chmod u=rwx,go=rx ftest
Pass three numbers to the chmod command to set normal permissions for files or directories. For example, "755" means that the owner has rwx permission, the group has rx permission, and others have tx permission.
To set special permissions for files or directories, just add a digit before these three numbers to place the special permissions set for files or directories
SUID,SGID,SBIT Corresponding numbers 4 --> SUID 2 --> SGID 1 --> SBIT If you want to set a file permission to -rwsr-xr-x: The normal permissions for this file are 755, In addition, this file has SUID Permission, so just add before 755 SUID The corresponding number is 4. That is, just execute chmod 4755 The file name command is complete-rwsr-xr-x Permission setting.
The general permission of - rwsr-xr-x is 755. It can be understood that the permission bits marked with s and t are hidden with X permission. Similarly, if a file has SUID and SGID permissions, you only need to pass 6 -- (- represents a number) to the chmod command; If a directory has SGID and SBIT, you only need to pass 3 --- to the chmod command.
Note that different special permissions affect different objects. SUID is only valid for executable files; SGID is valid for executable files and directories; SBIT is only valid for directories. Of course, you can also set 7 --- for files, that is, assign SUID, SGID and SBIT to a file or directory
[root@localhost ~]# chmod 7777 ftest #Give SetUID, SetGID and SBIT permissions at one time [root@localhost ~]# ll ftest -rwsrwsrwt. 1 root root Apr 19 23:54 ftest # Although there is no error in the implementation process, it has no practical significance to do so.
2 alphabetic form
You can give SUID permission to the file through "u+s"; Give SGID permission to the file or directory through "g+s"; Give SBIT permission to the directory through "o+t".
[root@localhost ~]#chmod u+s, g+s, o+t ftest #Set special permissions [root@localhost ~]# ll ftest -rwsr-sr-t. 1 root root Apr 19 23:54 ftest [root@localhost ~]# chmod u-s, g-s, o-t ftest #Cancel special permission [root@localhost ~]# ll ftest -rwxr-xr-x. 1 root root Apr 19 23:54 ftest # This method is only to verify the feasibility of alphabetic form, which has no practical significance for ftest files.
3 hide x
When we use the chmod command to give special permissions to a file or directory, the x permissions existing in the original file or directory will be replaced with s or t. when we use the chmod command to eliminate the special permissions of a file or directory, the x permissions that originally disappeared will appear again.
This is because, whether SUID, SGID, or SBIT, they are only valid for files or directories with X permissions. Files or directories without x permission, even if given special permission, cannot perform their functions and have no meaning.
Given without x Give special permissions to files or directories with permissions [root@localhost ~]# chmod 7666 ftest [root@localhost ~]# ll ftest -rwSrwSrwT. 1 root root Apr 23:54 ftest # The corresponding permission bits will be marked as S (uppercase) and T (uppercase), which means that the set SUID, SGID and SBIT permissions are meaningless.