Linux users and the "least privilege" principle

Vamei Source: Http://www.cnblogs.com/vamei Welcome reprint, Please also keep this statement. Thank you!

As a Linux user, we don't need to be particularly concerned with the following mechanisms. However, when we write a Linux application, we should pay attention to the implementation of the following switches in the program (if necessary), so that our program conforms to the "least privilege" principle, do not leave the system a potential security risk. Give your program too much permission, like eating down the burger below:

An easy-to-eat burger: excessive "privilege"

Linux users have a user ID (username, UID) and a group identity (group ID, GID) after logging in (login) . In the context of Linux file management, we also see that each file has nine-bit permission descriptions that indicate which users are allowed to perform (read, write, or execute) the file.

(Refer to Linux file management background)

Generally, the user information of Linux is saved in /etc/passwd, the group information is saved in /etc/group, each line of the file represents a user/group. Early Linux saved passwords in/etc/passwd in the form of code names, and now they are stored in/etc/shadow in the form of a cipher, the form of encryption . Storing the password in/etc/shadow increases the security of the password because/etc/passwd allows everyone to view it, and/etc/shadow only allows the root user to view it.

Process Permissions

However, in Linux, the user's instructions are within the scope of the process. When we are working on a file, we need to run a program in the process, open the file in the process, and read, write, or perform the operation. Therefore, we need to pass the user's permissions to the process so that the process actually executes the operation. For example we have a file a.txt, a string in the file:

Hello world!

I am logged in as a user Vamei and run the following command in the shell:

$cat A.txt

The entire running process and file reads are as follows:

We can see that we have two processes in the process, one is the shell itself (2256), one is the shell that replicates itself, and then runs/bin/cat (9913). The fork in the graph, exec, and PID can be see the Linux Process Foundation. The second process has performed a total of two operations on the file system, one at a time (x) file/bin/cat, and the other reading (r) file a.txt. Use $ls-l to view the permissions for these two files:

$ls-L/bin/cat

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

$ls-L A.txt

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

As can be seen from the above (refer to Linux file Management background),/bin/cat gives all users the right to execute, while Vamei as the owner of A.txt, has the right to read to A.txt.

Let's go into more details (the devil is in the details). In doing these two operations, although the user Vamei have the appropriate permissions, but we found that the real job is the process 9913. We want this process to have the appropriate permissions. In fact, each process is maintained with the following 6 IDs:

Real identity: Real UID, Real GID

Valid identity: Effective UID, effective GID

Storage identity: Saved UID, saved GID

Among them, the real identity is the identity that we use to log in, the valid identity is when the process really go to manipulate the identity of the file, storage identity is more special, we wait a bit further. When the process is fork, both true and valid identities are copied to the child process. In most cases, the true identity and valid identity are the same. When Linux finishes booting, the INIT process executes a login child process. We pass the user name and password to the login child process. After querying the/etc/passwd and/etc/shadow and determining its legitimacy, login runs (with exec) a shell process, and the real identity of the shell process is set to be the user's identity. Since the child processes that fork this shell process will inherit the true identity thereafter, the true identity will persist until we log out and sign in another identity (when we use SU as root, we are actually logged in as root, and then the real identity becomes root).

principle of least privilege

Why does each process not simply maintain its true identity, but choose to bother to maintain a valid identity and storage identity? This involves the principle of "least privilege" (least priviledge) of Linux. Linux usually expects a process to have only enough privileges to do its job, rather than to give it more privileges. In design, the simplest is to give each process the privilege of super user, so that the process can do what it wants to do. However, this is a huge security vulnerability for the system, especially in multi-user environments, where each user enjoys unrestricted privileges and can easily destroy other users ' files or the system itself. "Least privilege" is the privilege of shrinking a process to prevent the process from abusing its privileges.

However, different stages of a process may require varying privileges. For example, the first valid identity of a process is the real identity, but when running to the middle, you need to read some configuration files as other users, and then do other things. To prevent other user identities from being abused, we need to make the process's valid identity changes back to the real identity before the operation. In this way, the process needs to change between two identities.

a stored identity is another identity other than a real identity. When we execute a program file as a process, the owner of the program file (owner) and the owning group (owner) can be stored as the process's storage identity. During the subsequent process, the process will be able to choose to copy the real or stored identity to a valid identity to have the true identity or the right to store the identity. not all program files are set to store identities during the execution of the process. The program file that needs to do this will change the X of its nine-bit (bit) permission's execution bit to S. At this point, this bit is called the set UID bit or set GID bit.

$ls-L/usr/bin/uuidd-rwsr-sr-x 1 libuuid libuuid 17976 Mar 2012/usr/sbin/uuidd

When I run this program as root (UID), Root (GID), because the owner (owner) has the S bit set, the saved UID is set to become the Libuuid,saved GID is set to Libuuid. In this way, the UUIDD process can switch between two identities.

We usually use chmod to modify the Set-uid bit and set-gid bit:

$chmod 4700 File

We see that there are no more than three digits behind the chmod. The first one is used to process the Set-uid bit/set-gid bit, which can be set to be 4/2/1 as well as the number above and the. 4 is represented as the set UID bit, and 2 is expressed as the set GID bit,1 as sticky bit (temporarily not introduced). You must first have an X-bit basis to set the S-bit.

Summary

Real/effective/saved Uid/gid

Saved Uid/gid bit

The "least privilege" principle

Linux users and the "least privilege" principle