Actual user ID, valid user ID, and set user ID

Actual user ID, valid user ID, and set user ID

 

These concepts are often encountered when reading Unix-related books, but these concepts have not been properly clarified, so that they have been completely understood. I have made a distinction between these concepts and summarized them as follows. To put it bluntly, these UIDs are used for system permission management.

 

The following uses ruid, EUID, and SUID to represent the actual user ID, valid user ID, and set the user ID. In addition, the user ID is an integer. For convenience, the user name is used to represent different UIDs. First, explain the functions of these IDs:

Ruid, used to identify a user in the system. When the user successfully logs on to the next UNIX System Using the user name and password, his ruid is uniquely identified.

EUID, used by the system to determine the user's access permissions to system resources, which is generally equal to ruid.

SUID, used to open external permissions. Unlike ruid and EUID, a user is bound to a file rather than a user.

 

Many books have briefly mentioned the passwd program in SUID. The example below is used for analysis. We know that all Linux passwords are stored in the/etc/shadow file. This file is so important that you should back up it before making any changes. View the attributes of the/etc/shadow file as follows:

 

[[Email protected] ~] # Ll/etc/shadow

-R -------- 1 Root 1144 Jul 20/etc/shadow

 

It can be seen from the above that the/etc/shadow file is a file belonging to the root user and the root group, and only the EUID root user has the read permission, and all other euids do not have any permissions. When you try to open this file with vim in the shell of Steve user (EUID is also Steve at this time), the system will prompt that the permission is not allowed. Even the root user has only the read permission. I guess it is intended not to encourage the root user to directly modify it using the vim editor, but to use the passwd command to modify the file. If you need to modify it directly, you can use the CHMOD command to change the attribute to root writable, and then you can modify it.

 

Anyone who has used UNIX systems knows that any user can use the passwd command to set their own passwords. But as we already know from the above, non-root user logs cannot read this file, so how do common users modify this file? We know that the program actually executed by the passwd command is/usr/bin/passwd. Check the file attributes as follows:

 

-R-s -- X 1 Root 21944 Feb 12 2006/usr/bin/passwd;

 

The S-bit corresponding to the file access Mark is generally the SUID bit. In addition, we can see that all users have the right to execute this program. When the Steve user executes the passwd command. Shell will fork a sub-process. At this time, the EUID of the process is still Steve, and then the exec Program/usr/bin/passwd. Exec sets the EUID of the process to root Based on the SUID bit of/usr/bin/passwd. At this time, the process obtains the root permission and the read/write/etc/shadow file permission, so that Steve can modify the password. After exec exits, the Steve user's EUID will be restored to Steve. In this way, the Steve user will not always have root permissions.

 

We can test to remove the SUID bit of/usr/bin/passwd with the root user, as shown below:

[[Email protected] ~] # Ll/usr/bin/passwd

-R-s -- X 1 Root 21944 Feb 12 2006/usr/bin/passwd

[[Email protected] ~] # Chmod U-S/usr/bin/passwd

[[Email protected] ~] # Ll/usr/bin/passwd

-R-X -- X 1 Root 21944 Feb 12 2006/usr/bin/passwd

 

Then, the following error is prompted when Steve uses the passwd command to update the password:

[[Email protected] ~] $ Passwd

Changing password for user Steve.

Changing password for Steve

(Current) UNIX password:

Passwd: authentication token manipulation Error

[[Email protected] ~] $

This is because, after removing the SUID of the/usr/bin/passwd program, the Steve user can execute this program, but the SUID of/usr/bin/passwd/is not set, in this way, the EUID of the process after exec is still Steve.

 

Some people may find that the root user can still use the command to change the password, because the root user's EUID is root (it is also possible that the EUID will not be checked as long as it is found that the ruid is root, can read and write directly, root is the boss), can read the password file.

 

In addition, some people may find that the SUID bit can be set for common text files, but this is meaningless, because the file has no place to execute seteuid () to change the user's EUID.

 

Finally, the rules for user IDs also apply to group IDs.

 

The actual UNIX user ID and valid user ID analysis are reading apue today. These two problems are hard to understand. Google, there is an article that makes a good conclusion. After reading this article, we can understand it thoroughly.

Users often encounter SUID and SGID concepts in UNIX, and SUID and SGID are related to system security, so users are also concerned about this issue. Some people often ask questions about SUID and SGID, but the answer is generally not detailed enough. In addition, I have answered questions from two netizens and found some information, I decided to sort out the cost documents for your reference. Due to my own level problems, if any improper content is found in the article, please correct the majority of users.

1. Representation and parsing of file permissions in UNIX

SUID is set user ID, and SGID is set group ID.

In UNIX, you can run the LS-l command to view the file permissions. The format of the representation obtained by using the LS command is similar to-rwxr-XR-X. The meaning of the format is parsed below. There are 10 such representation methods:

9 8 7 6 5 4 3 2 1 0
-R w x r-x

9th bits indicate the file type, which can be P, D, L, S, C, B, and -:

P indicates the named pipe file.
D indicates the directory file.
L indicates the symbolic connection file
-Common File
S indicates the socket File
C Indicates the character device file.
B Indicates the block device file.

The 8-6, 5-3, and 2-0 digits respectively indicate the permissions of the file owner, the permissions of users in the same group, and the permissions of other users, in the form of rwx:

R indicates readable and can read the file content.

W indicates writable. You can modify the file content.

X indicates executable. This program can be run.

A location with no permissions is represented -.

Example:

Ls-l myfile:

-Rwxr-x --- 1 Foo staff 7734 APR 05 :07 myfile

Myfile indicates that the file is a common file, the file owner is the foo user, and the foo user belongs to the staff group. The file has only one hard connection and the length is 7734 bytes. The last modification time is on January 1, April 5.

The owner Foo has the read and write permissions on the file. The members of the staff group have the read and execute permissions on the file. Other users have no permissions on the file.

If a file is set with a suid or sgid bit, it is displayed in the executable bit of the permission of the owner or users in the same group. For example:

1.-rwsr-XR-X indicates that the executable bits in SUID and owner permission are set.

2.-rwsr -- r -- indicates that the SUID is set, but the executable bit in the owner permission is not set.

3.-rwxr-Sr-X indicates that the executable bits of SGID and the same group of users are set.

4.-RW-r-Sr -- indicates that the sgid is set, but the executable bits in the same group are not

In UNIX, the File Permission is represented by 12 binary bits. If the value at this location is

1 indicates that you have the following permissions:

11 10 9 8 7 6 5 4 3 2 1 0
S g t r w x r w x

The 11th bits are SUID bits, the 10th bits are SGID bits, and the 9th bits are sticky bits. The 8-0 bits correspond to the preceding three groups of rwx bits.

11 10 9 8 7 6 5 4 3 2 1 0

The value of-rwsr-XR-x above is: 1 0 0 1 1 1 0 1 1 0 1 0 1 1

-RW-r-Sr -- Value: 0 1 0 1 0 1 0 0 1 0 0 0

The command to add SUID and SUID to the file is as follows:

Set SUID bit for chmod U + S filename

Remove SUID settings from chmod u-s filename

Set the sgid bit for chmod g + S filename

Remove SGID settings from chmod g-s filename

Another method is to set the CHMOD command with octal representation. If you understand the previous 12-bit permission representation, it is also very easy.

Ii. Detailed analysis of SUID and SGID

Because SUID and SGID work in the execution program (the executable bit of the program is set), the executable bit only makes sense to common files and directory files, therefore, setting the SUID and SGID bits of other types of files does not make much sense.

First, we will talk about the SUID and SGID functions of common files. Example:

If the myfile of a common file belongs to the user Foo, it can be executed. Currently, no SUID is set. The LS command is shown as follows:

-Rwxr-XR-x 1 Foo staff 7734 APR 05 myfile any user can execute this program. What is the UNIX Kernel used to determine the resource access permissions of a process? Is the (valid) ID of the running user of the process, including the user ID and group ID. You can use the id command to find your or other user's user ID and group ID.

In addition to the common user ID and group ID, there are two other valid IDs, namely valid IDs. The four IDs above are represented as: uid, GID, EUID, and EGID. The kernel mainly uses EUID and EGID to determine the process's access permissions to resources.

If a process does not have a suid or sgid bit, EUID = uid EGID = GID, which is the UID and gid of the user who runs the program. For example, the UID and gid of the user Kevin are 204 and 202 respectively, the UID and gid of the user Foo are 200,201, And the EUID = uid = 204 of the Process Formed by running the myfile program, EGID = gid = 202. The kernel determines the process's resource access restrictions based on these values. In fact, Kevin's user's resource access permissions are irrelevant to foo.

If SUID is set for a program, EUID and EGID are changed to the UID and gid of the owner of the program to be run. For example, if the Kevin user runs myfile, EUID = 200, EGID = 201, uid = 204, gid = 202, the process has the resource access permission of its owner Foo.

The role of SUID is to allow a user who does not have the corresponding permissions to access resources when running this program. Passwd is a clear example.

SUID has a higher priority than SGID. When SUID is set for an executable program, SGID automatically becomes the corresponding EGID.

The following is an example:

UNIX systems have a/dev/kmem device file, which is a character device file that stores the data to be accessed by the core program, including the user's password. Therefore, this file cannot be read and written to normal users. The permission is set to Cr -- r ----- 1 Root System 2, 1 May 25 1998 kmem.

But PS and other programs need to read this file, and the PS permission settings are as follows:

-R-XR-Sr-x 1 Bin System 59346 APR 05 1998 PS

This is a program with SGID set, and PS users are bin, not root, so SUID cannot be set to access kmem, but you have noticed that both bin and root belong to the system group, in addition, PS sets the sgid. Generally, when you execute ps, you will get the permissions of the system group users, while the permissions of the users in the same group of file kmem are readable, therefore, it is normal for users to execute ps. But some people say, why not set the PS program as the root user program and then set the SUID bit? This can solve the problem, but why not do it? Because the risk of SGID is much lower than that of SUID, we should try to replace the SUID program with SGID for system security considerations, if possible. The following describes the effect of SGID on the directory. SUID does not affect the directory. If an SGID bit is set for a directory, if any user has the write permission for this directory, the group of files created in this directory will be automatically converted to the group where the owner of this directory is located, and the file owner remains unchanged.

3. Programming SUID and SGID

The following header files and functions are closely related to SUID and SGID programming:

 

# Include

# Include

 

Uid_t getuid (void );

 

Uid_t geteuid (void );

 

Gid_t getgid (void );

 

Gid_t getegid (void );

 

Int setuid (uid_t UID );

 

Int setruid (uid_t ruid );

 

Int seteuid (uid_t EUID );

 

Int setreuid (uid_t ruid, uid_t EUID );

 

Int setgid (gid_t GID );

 

Int setrgid (gid_t rgid );

 

Int setegid (git_t EGID );

 

Int setregid (gid_t rgid, gid_t EGID );

 

The specific descriptions of these functions are not listed in detail here. You can use man to query them.

 

 

SUID/SGID:

Assume that you have a file named a.txt.

# Ls-l a.txt

-Rwxrwxrwx

# Chmod 4777 a.txt

-Rwsrwxrwx ====> note s location

# Chmod 2777 a.txt

-Rwxrwsrwx ====> note s location

# Chmod 7777 a.txt

-Rwsrwxswt ====> the Tsung memory is saved to a.txt, saving the system reload time.

 

Now let's look at the effect of setting SUID/SGID above:

# Cd/sbin

#./Lsusb

...

# Su AAA (Common User)

$./Lsusb

...

Is an error displayed now?

$ Su

# Chmod 4755 lsusb

# Su aaa

$./Lsusb

 

... Do you understand now? This is a command that can only be executed by the root user. After SUID is added, normal users can use the command like root, and the permission is improved. The above is for the file, and the directory is similar!

The S attribute of the Directory makes any files and subdirectories created under the directory belong to the group owned by the Directory. The T attribute of the Directory allows the owner and root of the directory to delete the directory. For S and S, you must have the operation permission to set SUID/SGID. Otherwise, you will see s after using LS-L to prove that the SUID/SGID you set does not work.

 

Why we need SUID, how do we use SUID?

 

R -- Read access

 

W -- Write Access

 

X -- execute the license

 

S -- SUID/SGID

 

T -- Sticky Bit

 

So what is SUID/SGID? Why is there a SUID?

 

To understand this, let's take a look at the question: If you want each user to change their own password?

 

You can run passwd to change the password. In the end, you must modify the/etc/passwd file, and the attributes of the passwd file are:

 

# Ls-L/etc/passwd

 

-RW-r -- 1 Root 2520 Jul 12 18:25 passwd

 

We can see that the passwd file is only writable to the root user, but not to all other users. How can a common user modify the passwd file by running the passwd command?

 

To solve this problem, SUID/SGID came into being. At&t applied for a patent for it. Haha.

 

How does SUID and SGID solve this problem?

 

First, we need to know that the process has some attributes, including the actual user ID, actual group ID, valid user ID, and valid group ID, when running. The actual user ID and the actual group ID identify who we are and who is running this program. Generally, these two fields are determined at login, and these values remain unchanged during a login session.

 

The valid user ID and valid group ID determine the permissions of the process at runtime. When determining whether a process has the file access permission, the kernel uses the valid user ID of the process for determination.

 

Now that we know this, let's take a look at the SUID solution:

 

When a program is set to a SUID bit, the kernel will know that when running this program, it should be considered that the file owner is running this program. That is, when the program runs, the valid user ID is the owner of the program. For example:

 

[[Email protected] bin] # ls-l passwd

 

-R-s -- X 1 Root 16336 Feb 14 2003 passwd

 

Although you log on to the system using test, when you enter the passwd command to change the password, because passwd sets the SUID bit, although the actual user ID of the process is the ID of the test, however, the valid user ID of a process is the root ID of the owner of the passwd file. Therefore, you can modify the/etc/passwd file.

 

Let's look at another example.

 

The Ping Command is widely used to test whether the network connection is normal. Ping uses the ICMP protocol during running and sends ICMP packets. However, only the root user can establish ICMP packets. How can this problem be solved? SUID is also used.

 

[[Email protected] bin] # ls-L/bin/ping

 

-Rwsr-Sr-x 1 Root 28628 Jan 25 2003/bin/ping

 

We can test it. If we remove the ping SUID and run the command with a common user, what will happen.

 

[[Email protected] bin] # chmod U-S/bin/ping

 

[[Email protected] bin] # ls-l Ping

-Rwxr-XR-x 1 Root 28628 Jan 25 2003 Ping

 

[[Email protected] bin] # su Test

 

[[Email protected] bin] $ Ping byhh.net

 

Ping: ICMP open socket: operation not permitted

 

Although SUID solves some problems, it also brings some security risks.

 

Because if a program with a SUID bit set is attacked (through buffer overflow and other aspects), hacker can get the root permission.

 

Therefore, pay special attention to the programs with SUID settings in terms of security.

 

Run the following command to find all SUID files on the system:

 

[[Email protected]/] # Find/-Perm-04000-type F-ls

 

For the reason why this is 4000, you can see the meaning of each bit in the previous st_mode.

 

In these programs with SUID set, if it cannot be used, it is best to cancel the SUID bit of the program.

Actual user ID, valid user ID, and set user ID