Deep understanding of setuid

Http://student.csdn.net/space.php? Uid = 129820 & Do = Blog & id = 40308

* Originally published in "grass-roots" magazine,: http://www.lampbrother.net/grassroots/

In Linux, every common user can change his/her password, which is a reasonable setting. The problem is: the user information is saved in the/etc/passwd file, and the user password is saved in the file/etc/shadow, that is to say, when you change your password, the encrypted password in the/etc/shadow file is modified. However, look --

-RW-r -- 1 Root 1787 Oct 27 2009/etc/passwd

-R -------- 1 Root 1187 Oct 27 2009/etc/shadow

Each user of the/etc/passwd file has the read permission, but only the root user has the write permission. Only the root user of the/etc/shadow file has the read and write permissions, that is to say, a common user does not have the write permission on these two files and cannot write a new password. Why can a common user change the password?

PS: set or change the user password in Linux. It is first written to the/etc/passwd file and then converted to the/etc/shadow file through the pwconv command, run the pwunconv command to observe the effect before conversion. The/etc/shadow file disappears magically, in the/etc/passwd file, the original XX address is changed to a real encrypted password.

 

In fact, the real secret that a user can change the password is not the file permission, but the passwd command for changing the password.

-Rwsr-XR-x 1 Root 22960 Jul 17 2006/usr/bin/passwd

The passwd command has a special permission Mark S, which exists on the permission bit of the file owner. This is a special type of permission setuid, which can be understood as follows: when the setuid permission is set for a file with the execution permission, the user executes the file as the file owner. The passwd command has the setuid permission, and the owner is root (the default owner of Linux commands is root). That is to say, when a common user uses passwd to change his password, the soul is suddenly attached, it is actually executed as the passwd command owner root. Of course, root can write the password to the/etc/shadow file (do not forget that the root guy is a superuser and can do anything ), after the command is executed, the identity disappears.

 

You can try to use the root identity to modify the passwd command permission to remove setuid:

Chmod U-S/usr/bin/passwd

After logging on as a common user, you will find the following prompt:

Passwd

Changing password for user Samlee.

Changing password for Samlee

(Current) UNIX password:

Passwd: authentication token manipulation Error

Ordinary users cannot change their passwords, so they only need to understand why ordinary users can change their passwords and understand the role of setuid permissions.

 

Next we will use two setuid rationale to further interpret its concept --

 

Case 1: Example of setuid authorization

 

For better understanding of setuid, I will use the touch command as an example.

Normal user Samlee uses touch to create the file newfile01:

Touch newfile01

Ls-l newfile01

-RW-r -- 1 Samlee 0 05-21 0:20 newfile01

The creator of the file is the owner by default, so the owner of newfile01 is Samlee.

The administrator root adds the setuid permission to the touch command:

Chmod U + S/bin/touch # Or chmod 4755/bin/touch

Ls-L/bin/touch

-Rwsr-XR-x 1 Root 42284 Jul 13 2009/bin/touch

Create the file newfile02 with the normal user Samlee. the following result is displayed:

Touch newfile02

Ls-l newfile02

-RW-r -- 1 root Samlee 0 05-21 0:48 newfile02

In this example, we can interpret the definition of setuid. When the setuid permission is set for an executable file (command touch), when a common user Samlee executes touch to create a new file, this operation is actually performed as the touch command owner root. Since it is executed as root, of course, the owner of the new file is root, which is the role of setuid.

 

Let's take a look at the setgid permission similar to setuid. Let's look at an example and grant the setgid to the touch command:

Chmod g + S/bin/touch # Or chmod 6755/bin/touch

Ls-L/bin/touch

-Rwsr-Sr-x 1 Root 42284 Jul 13 2009/bin/touch

In this case, use touch to create the new file newfile03, and you will see the following phenomenon:

Touch newfile03

Ls-l newfile03

-RW-r -- 1 Root 0 05-21 0:48 newfile02

The group to which the new file belongs is the group of the touch command, rather than the group of Samlee, a common user executing the touch command. This is the role of setgid, similar to setuid, when a user executes a command with a setgid, the user will call the identity of the group to which the command belongs.

 

Case 2: Dangerous setuid

 

For the use of setuid, you can make a metaphor: A secret authority, to allow some people to come in to do something, but not let them see the internal situation of the Agency, so authorize some special "vehicles" (there is no window, the door is closed, you can't see the outside, there is only one small hole to allow the ride people to work out), take the ride people to the place to go, allow it to bring it out immediately after it completes the task. Is this safe? Not necessarily. If the "vehicle" is not carefully selected, there may be many "Doors and windows", it may be dangerous. This type of scenario is believed to have been seen many times in some police films.

When you use VI to edit the/etc/shadow file, the system prompts "Permission denied". This is a reasonable setting. However, if you grant vi the setuid permission:

Chmod U + S/bin/VI

Ls-L/bin/VI

-Rwsr-XR-x 1 Root 594740 Jun 12 2009/bin/VI

In this case, a common user can use VI to edit the/etc/shadow file. As a root user, the user can perform any read/write operations (such as clearing any user password bit, you do not need to enter a password for Logon ). However, you cannot view the content of the/etc/shadow file by using commands such as more and Cat. Only the VI granted with setuid can be viewed and modified. Similarly, if a VI has the setuid permission, a common user can change his UID to 0 by editing the/etc/passwd file in VI, then his permission is the same as that of root; you can edit the/etc/inittab file in VI to change the default running level to 6, so that Linux will restart continuously after it is started ......

 

Let's take a look at the disturbing situation and try to close the apache service with common users:
PS-Le | grep httpd

140 s 0 8916 1 0 76 0-3697 -? 00:00:00 httpd

Killed 8916

-Bash: Kill: (8916)-operation not permitted

As you can see, normal users cannot close the process started by the root user, but if you do the following:

Chmod 6555/bin/kill

Now, when a common user executes kill, because kill is granted the setuid permission, it has the root permission at the moment of execution, as long as the user does not want to close any service!

 

Therefore, the setuid permission cannot be set at will, and malicious modification by hackers should be prevented. Some suggestions are provided to avoid the security impact of setuid:
1. Write Permissions should be strictly controlled for key directories. Such as "/" and "/usr;
2. the user's password should be strong enough, with more than 8 characters, a combination of uppercase and lowercase letters, numbers, and symbols, such as am @ ri31n, and should be changed regularly;
3. List the files in the system that should have the setuid permission, and regularly check whether there are other files with the setuid permission.

 

You can list the files in the system that should have the setuid permission, and regularly check whether the commands that are not in the list are set with the setuid permission.
After installing and deploying Linux, run the following command to generate the setuid list file:

Mkdir/script # create a directory/script

Find/-Perm-4000-o-Perm-2000>/script/setuid. List

Run the "-Perm" command to specify the File Permission. The number of the setuid permission bit is marked as 4, and the number of the setgid permission bit is marked as 2, the "000" mark is followed by no restriction on the permissions of the other three types of users in the owner's group. "-o" indicates or, that is, files with setuid or with setgid are in the search column, the generated search results are stored in the file/script/setuid. list.

 

Run the following shell program to check the system. You can also perform regular checks in scheduled tasks.

/Usr/bin/find/-Perm-4000-o-Perm-2000>/tmp/setuid. Check

For file in '/bin/CAT/tmp/setuid. Check'

Do

/Bin/grep $ File/script/setuid. List>/dev/null

If ["$? "! = "0"]

Then

Echo "$ file isn' t in list! It's danger !! "

Fi

Done

/Bin/RM/tmp/setuid. Check
If the command kill is set to setuid, the system will check the prompt:

/Bin/kill isn' t in list! It's danger !!

 

In addition, if you want to disable the setuid function in some data storage partitions, you can also make the following settings, edit the configuration file/etc/fstab, and find the partition to be set (such as/home) corresponding setting line:

VI/etc/fstab

Label =/home ext3 defaults 1 2

After "ults" is set, add the "nosuid" option and re-mount the/home partition:

VI/etc/fstab

Label =/home ext3 defaults, nosuid 1 2

Mount-O remount/home

After the preceding settings, no executable file in the partition/home cannot be executed even if the setuid permission is set. (You can copy a setuid command to the/home directory to execute the experiment ), this setting is performed on partitions that store data and are used for backup and other functions to protect system security.

 

Friendly reminder: After completing the experiment in this article, do not forget to restore the File Permission to the original state, so as to avoid unnecessary trouble.
So far, I believe that the reader has some knowledge about the role of setuid. Finally, there is another issue that everyone should pay attention to. setuid is only valid for files with executable permissions, if a file that does not have the X permission is granted the setuid, it is marked as S. If you do not have the executable permission, it makes no sense to set the setuid.