Linux under setuid Command! Reproduced

Linux under setuid Command!reproduced

Every ordinary user in a Linux system can change their own password, which is a reasonable setting.

The problem is: the user's information is saved in the file/etc/passwd, the user's password is saved in the file/etc/shadow, that is, the user changes their password is the/etc/shadow file to modify the encryption password, but,

-rw-r--r--1 root root 1787 Oct 2009/etc/passwd

-R--------1 root root 1187 Oct 2009/etc/shadow

/etc/passwd file Each user has Read permissions, but only Root has Write permission,/etc/shadow file only Superuser root has read and write permissions, that is, the average user has no write permission to the two files can not write the new password, why ordinary users can change the password?

PS: Set or change the user password in Linux, is written to the/etc/passwd file and then through the Pwconv command to convert to/etc/shadow file, the execution Pwunconv command can observe the pre-conversion effect, will observe the/etc/ The shadow file magically disappears, and the original x in the/etc/passwd file becomes the real encryption password.

In fact, the user can change the password the real secret is not the permissions of the file, but the command to change the password passwd.

-rwsr-xr-x 1 root root 22960 Jul 2006/usr/bin/passwd

The passwd command has a special permission token s, which exists on the file owner's permission bit. This is a special kind of permission setuid, which can be understood: When a file with Execute permission is set setuid permission, the user executes the file as the owner of the file. The passwd command has setuid permissions and the owner is root (the command default owner in Linux is root), which means that when a normal user uses passwd to change their password, suddenly the soul is possessed, Actually in the passwd command owner root, root can certainly write the password to the/etc/shadow file (do not forget that the root of this guy is superuser can do anything), the command after the completion of the identity will disappear.

You can experiment with root to modify passwd command permissions to remove setuid:

chmod u-s/usr/bin/passwd

Try to change the password after logging in as a normal user, you will find the prompt:

passwd

Changing password for user Samlee.

changing password for Samlee

(current) UNIX Password:

Passwd:authentication Token manipulation Error

Ordinary users can not change the password, so as long as the ability to understand why ordinary users can change the password to probably understand the role of setuid permissions.

Next we use two setuid to further explain its concept--

Case ONE: setuid Authorization example

To facilitate an in-depth understanding of the setuid, I use the touch command as an example to do a demonstration.

Normal user Samlee Create file newfile01 with touch:

Touch newfile01

Ls-l newfile01

-rw-rw-r--1 samlee samlee 0 05-21 01:20 newfile01

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

Admin root adds setuid permissions to the Touch command:

chmod U+s/bin/touch # or chmod 4755/bin/touch

Ls-l/bin/touch

-rwsr-xr-x 1 root root 42284 Jul 2009/bin/touch

Then use the ordinary user Samlee to create the file Newfile02, see the following results:

Touch NEWFILE02

Ls-l NEWFILE02

-rw-rw-r--1 root samlee 0 05-21 01:48 newfile02

In this example, we can then interpret the definition of setuid, when an executable (command Touch) Set setuid permissions, when the ordinary user Samlee to perform touch to create a new file, actually as the touch command owner root in the role of doing this operation, Since it is executed as root, of course, the owner of the new file is root, which is the role of setuid.

Take a look at the Setgid permissions similar to Setuid, and for an example, Grant setgid the Touch command:

chmod G+s/bin/touch # or chmod 6755/bin/touch

Ls-l/bin/touch

-rwsr-sr-x 1 root root 42284 Jul 2009/bin/touch

At this point, using touch to create a new file newfile03, you will see the following behavior:

Touch newfile03

Ls-l newfile03

-rw-rw-r--1 root root 0 05-21 01:48 newfile02

The owning group for the new file is the group that owns the Touch command, not the owning group of the normal user Samlee that performs the Touch command, which is setgid, similar to setuid, where a user invokes the identity of the group that the command belongs to when it executes a command with Setgid.

Case two: Dangerous setuid

For the use of setuid, you can do a metaphor: a top secret authority, to let some people come in to do some things, but can not let them see the situation inside the organ, so authorized some special "vehicle" (no window, door closed, see outside, only a small hole to allow the person to reach out arm work), Take the person you are travelling to where you want to go, and allow it to be done immediately. Is that safe? Not necessarily. If the "vehicle" is not carefully selected, there may be a lot of "doors and windows", that can be dangerous, this similar scenario is believed to have been seen in some police and gangster movies many times.

The normal user uses VI to edit the/etc/shadow file will prompt "Permissiondenied", this is reasonable setting, but if give VI with SETUID permission:

chmod U+s/bin/vi

Ls-l/bin/vi

-rwsr-xr-x 1 root root 594740 June 2009/bin/vi

At this point, ordinary users can edit the/etc/shadow file using VI, because the root identity, can do any read and write operations (such as can be any one user password bit emptied, the user login does not need to enter a password). However, the use of more, cat and other commands still cannot view the contents of the file/etc/shadow, only the VI granted to SETUID can be viewed and modified. Similarly, if the VI has the SETUID permission, the ordinary user can edit the/etc/passwd file of the VI to change their UID to 0, then his authority is the same as root; You can edit the/etc/inittab file to change the default RunLevel to 6. Then Linux will restart after booting ...

Let's look at a disturbing situation and try to close the Apache service with a normal user:
Ps-le | Grephttpd

S 0 8916 1 0 76 0-3697-? 00:00:00 httpd

Kill 8916

-bash:kill: (8916)-Operation not permitted

As you can see, a normal user cannot close the root-initiated process, but if you do one of the following actions:

chmod 6555/bin/kill

Now when a normal user executes kill, because Kill is granted the setuid permission, in the instant of execution has the root authority, as long as the user is uncomfortable want to shut down any service can!

Therefore, setuid permissions can not be set casually, at the same time to prevent hackers malicious modification, how to avoid setuid the impact of insecurity, there are a few suggestions:
1. The key directory should strictly control write permissions. such as "/", "/usr" and so on;
2. The user's password is strong enough, more than 8, uppercase and lowercase letters, numbers, symbols combination, such as: [email protected], and regular replacement;
3. Make a list of the files in the system that should have setuid permissions, and check that there are no files outside of this setuid permission set.

You can make a list of files in the system that should have setuid permissions, and check that there are no commands in the non-list that have setuid permissions set.
After the Linux installation deployment is complete, execute the following command to generate the setuid list file:

Mkdir/script # Create directory/script

Find/-perm-4000-o-perm-2000 >/script/setuid.list

The command find option "-perm" for the specified file permission, the setuid permission bit corresponds to a digital ID of 4, the Setgid permission bit corresponds to a digital ID of 2, and the following is written as "000" to identify the rights of the three categories of users who belong to the group to which the owner belongs; "-O" denotes or, Is that the file has setuid or has setgid in the search column, the resulting search results are stored in the file/script/setuid.list.

When you need to check the system, execute the following shell program. It can also be placed on scheduled tasks for timed checks.

/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
Assuming that the command kill is set to Setuid, the prompt is detected:

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

In addition, if you want to disable the setuid feature in some data storage partition, you can also make the following settings, edit the configuration file/etc/fstab, and locate the setting line for the partition you want to set (for example,/home):

Vi/etc/fstab

Label=/home/home ext3 Defaults 1 2

After setting "Defaults", add "nosuid" option and re-mount the/home partition:

Vi/etc/fstab

Label=/home/home ext3 defaults,nosuid 1 2

Mount-o Remount/home

After setting, any executable file on the partition/home will not execute even if the setuid permission is set (the reader can copy a setuid command to perform the experiment in the/home directory), which can be used to protect the system security by doing this on some partitions that hold the data and use it for backup functions.

Friendship Tip: Please finish the experiment in this article, do not forget to restore the permissions of the file, so as not to bring unnecessary trouble.

At this point, I believe that the reader has been aware of the role of setuid, and finally, there is a need to pay attention to the issue, setuid only for the file with executable permissions valid, does not have the X permission of the file is granted setuid will display marked S (suddenly by small s into a sister), think carefully, Setting setuid does not make sense if there is no executable permission.

Linux under setuid Command! Reproduced