Linux users and the "minimum permission" Principle

After a Linux user logs on to login, it carries a user ID (UID) and a group ID (GID ). In the Linux File Management background, we can see that each file has nine more permissions to indicate which users are allowed to perform the operations (read, write, or execute ).

(ReferLinux File Management Background)

 

Generally, Linux User information is stored in/etc/passwd, and group information is stored in/etc/group. Each row of the file represents a user/group. In earlier Linux versions, passwords were stored in/etc/passwd in the form of name codes, but now they are mostly in the form of passwords (that is, encrypted form) in the/etc/shadow format. Storing the password in/etc/shadow improves the security of the password because/etc/passwd allows all users to view the password, while/etc/shadow only allows root users to view the password.

 

1. Process Permissions

However, in Linux, user commands are performed within the scope of processes. When we operate a file, we need to run a program in the process, open the file in the process, and read, write, or execute the operation. Therefore, we need to pass user permissions to the process so that the process can actually perform operations. For example, we have a file a.txt, which is a string:

Hello world!

I Log On As A Vamei user and run the following command in shell:

$ Cat a.txt

The entire running process and file reading are as follows:

 

We can see that there are two processes in the whole process, one is shell itself (2256), the other is shell replication itself, and then run/bin/cat (9913 ). For fork, exec, and PID in the figure, see Linux Process basics. The second process performs a total of two operations on the file system, one is to execute the (x) file/bin/cat, and the other is read (rw.file a.txt. Use $ ls-l to view the permissions of these two files:

$ Ls-l/bin/cat

-Rwxr-xr-x 1 root 46764 Apr 1 2012/bin/cat

$ Ls-l a.txt

-Rw-r -- 1 Vamei 14 Oct 7 09:14 a.txt

As you can see from the above (refer to the Linux File Management background),/bin/catenables all users to enjoy the right to execute, and vameias the owner of a.txt, and the right to read a.txt.

 

Let's go to more details (The dedevil is in the details ). During these two operations, although the user Vamei has the corresponding permissions, we found that the process is actually 9913. We need to grant the corresponding permissions to this process. In fact, each process maintains the following six IDs:

Real Identity: real UID, real GID

Valid identity: Valid UID, valid GID

Storage identity: saved UID, saved GID

The real identity is the identity used for login. The valid identity is the identity checked when the process actually operates the file. The storage identity is special. Let's wait for a while. When the fork process is used, both the real identity and valid identity are copied to the sub-process. In most cases, the real identity and valid identity are the same. After Linux is started, the init process executes a login sub-process. We pass the username and password to the login sub-process. After querying/etc/passwd and/etc/shadow and determining its validity, login runs (using exec) a shell process, the real identity of the shell process is set to the identity of the user. Since the subsequent fork sub-processes of this shell process will inherit the real identity, the real identity will continue, it is not until we log out and log on again as another user (when we use su to become the root user, we actually log on again as the root user, and then become the root user ).

 

2. Minimum permission Principle

Why does each process not simply maintain its real identity, but choose to maintain its valid identity and storage identity at full cost? This involves the Linux least priviledge principle. Linux usually wants a process to have only enough privileges to complete its work, instead of granting it more privileges. In terms of design, the simplest thing is to grant each process the super user Privilege so that the process can do what it wants. However, this is a huge security vulnerability for the system, especially in multi-user environments. If every user has unlimited privileges, it is easy to damage the files or systems of other users. The "minimum privilege" is the privilege to contract the process to prevent the process from abusing the privilege.

However, different stages of a process may require different privileges. For example, when a process starts with a valid identity, it must read some configuration files as other users before performing other operations. To prevent other user identities from being abused, we need to change the valid identity of the process to a real identity before the operation. In this way, the process needs to change between two identities.

The storage identity is another identity other than the real identity. When we execute a program file as a process, the owner and owner group of the program file can be stored as the storage identity of the process. During subsequent processes, the process will be able to copy the real identity or storage identity to a valid identity to have the permissions of the real identity or storage identity. Not all program files are stored in the execution process. In this case, the program file will be changed to "s" for its nine-bit (bit) permission. At this time, this bit is called set UID bit or set GID bit.

$ Ls-l/usr/bin/uuidd
-Rwsr-sr-x 1 libuuid 17976 Mar 30 2012/usr/sbin/uuidd

When I run this program as root (UID) and root (GID), because the owner has s-bit settings, the saved UID is set to libuuid, the saved GID is set to libuuid. In this way, uuidd processes can switch between two identities.

 

We usually use chmod to modify set-UID bit and set-GID bit:

$ Chmod 4700 file

We can see that the chmod is no longer followed by three digits. The first bit is used to process the set-UID bit/set-GID bit. It can be set to 4/2/1 or the sum of the preceding numbers. 4 indicates set UID bit, 2 indicates set GID bit, and 1 indicates sticky bit (not introduced currently ). S-bit can be set only after x-bit.

 

As a Linux user, we do not need to pay special attention to the above mechanism. However, when writing a Linux application, you must implement the preceding switchover in the Program (if necessary ), this allows our programs to comply with the "minimum permission" principle without leaving potential security risks to the system. If your program has excessive permissions, it is like eating the following hamburger:

 

A vulnerable hamburger: excessive "Permissions"

 

Summary:

Real/valid tive/saved UID/GID

Saved UID/GID bit

"Minimum permission" Principle