Basic principles of Linux permission control

This article mainly introduces the basic principles of permission control in Linux systems.

Security Model

In the Linux system, all our operations are essentially operations of process accessing files. To access files, we need to obtain the corresponding access permissions first, and the access permissions are obtained through the security model in the Linux system.

For the security model in Linux systems, we need to know the following two points:

1. The original security model on the Linux system is called DAC, whose full name is Discretionary Access Control, which translates as discretionary access control.
2. Later, a new security model was added and designed called MAC, whose full name is Mandatory Access Control, which translates as mandatory access control.

Note that MAC and DAC are not mutually exclusive. DAC is the most basic security model and is usually the most commonly used access control mechanism that Linux must have. MAC is an enhanced security mechanism built on DAC. , is an optional module. Before access, Linux systems usually do a DAC check first. If it fails, the operation fails directly; if it passes the DAC check and the system supports the MAC module, it then does a MAC permission check.

To distinguish the two, we call the Linux system that supports MAC SELinux, which means that it is a security-enhanced system for Linux.

Here, we will talk about the DAC security model in Linux systems.

DAC Security Model

The core content of DAC is: In Linux, a process theoretically has the same permissions as the user executing it. Everything involved is centered around this core.

User and Group ID Information Control

User, group, password information

Save user and group information through /etc/passwd and /etc/group, and save passwords and their change information through /etc/shadow, with one record per line.

Users and groups are represented by UID and GID respectively. A user can belong to multiple groups at the same time. By default, each user must belong to a GID with the same UID value and the same name.

For /etc/passwd, each record field is user name: Password (encrypted and saved in /etc/shadow): UID: GID (default UID): Description comment: Home directory: Login shell (first run program of)

For /etc/group, the fields of each record are group name: password (generally there is no group password): GID: group member user list (comma-separated user UID list)

For /etc/shadow, the fields of each record are: Login name: Encrypted password: Last modification time: Minimum time interval: Maximum time interval: Warning time: Inactivity time:

Example

The following are examples of user and group information. The password information in /etc/shadow is encrypted and stored, no example is provided.

File permission control information

file type

File types in Linux are as follows:

• Ordinary files, including text files and binary files, can be created with touch;
• Socket file, used for network communication, is generally created indirectly by the application during execution;
• The pipe file is a named pipe, not an unnamed pipe, and can be created with mkfifo;
• Character files and block files are device files and can be created with mknod;
• The link file is a soft link file, not a hard link file, and can be created with ln.

Access Control Group

Divided into three groups for control:

• user contains the permissions set for the file owner
• group contains the permissions set for the file group
• others contains permissions set for others

Configurable permissions

Common (but not all) permission values ​​are given below, including:

• r means read permission.
• w means having write permission.
• x is generally for executable files/directories, indicating that it has execution/search permissions.
• s is generally for executable files/directories, indicating that it has the permission to grant the file owner permission. Only the user and group groups can set this permission.
• t Generally for a directory, after setting the sticky bit, users with permissions can only write and delete their own files, otherwise they can write and delete all files in the directory. The old system also means that after the executable file is run, the text is copied to the swap area to improve speed.

Example

You can check its file type and permissions through ls -l, and modify the permissions through chmod.

for example,

In the output, the first character indicates the file type, among which, ordinary file (-), directory file (d), socket file (s), pipe file (p), character file (c), block file (b), link file (l); The -rwxr-xr-x part starting from the second character represents the permission bit of the file, with a total of 9 bits.

For the file /usr/bin/qemu-i386, the meaning of this permission control is:

1. The rwx in bits 2~4 indicates that the file can be accessed by its owner with permissions of r, w, or x.
2. The r-x in bits 5~7 indicates that the file can be accessed by users in the same group as the file with r or x permissions
3. The r-x in bits 8~10 indicates that the file can be accessed by other unknown users with r or x permissions.

Permissions set for test/, test2/, test3/:

1. r,w,x permissions for each permission control group are represented by one octal number; for example: 755 means rwxr-xr-x.
2. s,t permission will be displayed instead of x position; to set s,t permission, you need to append a number before the corresponding octal permission control group used to control r,w,x; s permission is used for the owner Belongs to group control, t is used for other controls.
3. To set the owner s, add 4, to set the group s to add 2, and to set the permission of others t, add 1; for example, when setting t for test/, use 1775, which means rwxrwxr-t.

Process permission control information

Process permissions

For processes, the following attributes are related to file access permissions:

• effective user id: UID related to process access file permissions (abbreviated as euid).
• effective group id: GID related to process access file permissions (abbreviated as egid).
• real user id: UID (abbreviated as ruid) when the user who created the process logs in to the system.
• real group id: The GID (abbreviated as rgid) of the user who created the process when logging into the system.
• saved set user id: copied from euid.
• saved set group id: copied from egid.

Example

We can use ps and top to select and view processes with euid and ruid. Or use top to view the euid and ruid

of the process

Example to view via top:

First enter top to get something like the following

Here, the -d option is used to extend the refresh frequency of top for ease of operation. As can be seen here, only the USER field represents the effective user id of the corresponding process.

Open the display options of read user id:

a. While the top command is running, enter f, and you will see a line similar to the following:

b. Enter c to turn on the display switch of Real user name.

c. Finally, press Return to return to top, and you will see the real user id option. Enter `o` at this time to adjust the column order. Finally we can see the output including `effective user id` and `real user id` as follows:

Permission control policy for process access files

rule

Rough permission control strategy for process access files

For a process to access files, the most important thing is euid, so its permission attributes are all centered on euid.

• The euid of a process generally defaults to its ruid value
• If the executable permission bit of the executable file is s, after the process calls exec on it, its euid is set to the user id of the executable file
• The saved set user id of the process is copied from euid.
• When the euid of the process matches the user id of the file, the process only has the permissions set by the user permission bit of the file
• The control rules for group permissions egid are similar.

Modify permission attributes through exec execution file

When calling an executable file through exec:

• The process ruid value always remains unchanged;
• saved set-user ID is always from euid ;
• The euid value depends on whether the file's set-user-ID bit is set.

as follows:

Modify permission attributes through setuid(uid) system call

When modifying permission attributes through setuid(uid):

• superuser can smoothly modify ruid, euid, saved set-user ID;
• unprivileged user can only modify euid when uid is equal to ruid, and cannot be modified otherwise.

Example

Let’s give a few more special examples:

set-user-id

As mentioned earlier, the meaning of this output is that, for the /usr/bin/sudo file,

• The rws in bits 1~3 indicates that the file can be accessed by its owner with permissions of r or w or s
• The r-x in bits 4~6 indicates that the file can be accessed by users in the same group as the file with r or x permissions.
• The r-x in bits 7~9 indicates that the file can be accessed by other unknown users with r or x permissions.

After this setting, the owner has read, write, and execute permissions, which is no different. But for ordinary user processes that do not belong to the root group, it is quite different.

When an ordinary user process executes the sudo command, it obtains execution permissions through x in others, and then uses s in user to temporarily have the permissions of the owner (root) of the sudo executable file, that is, super permissions.

This is also why ordinary users can execute many commands with administrator privileges through the sudo command.

stick-bit is set

After this setting, everyone has read, write, and execute permissions for the /tmp directory. This is no different. However, the sticky bit t is set in the others part, and its function is quite different.

If the directory does not have the sticky bit set, anyone with write permissions to the directory can delete any files and subdirectories in it, even if he is not the owner of the corresponding file and does not have read or write permission; after the sticky bit is set, The user can only write or delete files and subdirectories that belong to him.

This is why anyone can write files and directories to the /tmp directory, but can only write and delete files or directories they own.

Give an application fragment of the man program to describe the use of set-user-id and saved set-user-id

The man program can be used to display online help manuals. The man program can be installed to specify set-user-ID or set-group-ID for a specified user or group.

The man program can read or overwrite files in certain locations, which is usually configured by a configuration file (usually /etc/man.config or /etc/manpath.config) or command line options.

The man program may execute some other commands to process the file containing the displayed man page.

To prevent processing errors, man switches between two privileges: the privileges of the user running the man command, and the privileges of the owner of the man program.

The main thread that needs to be grasped: When only man is executed, the process privileges are the privileges of the man user. When a child process is executed through man (such as a shell command through !bash), the user switches to the current user. After execution, the user switches to the current user. Switch back.

The process is as follows:

1. Assume that the man program file is owned by user man and has its set-user-ID bit set. When we exec it, we have the following situation:
   – real user ID = our user UID
   – effective user ID = man user UID
   – saved set-user-ID = man user UID
2. The man program will access the required configuration files and man pages. These files are owned by the man user, but since the effective user ID is man, access to the files is allowed.
3. When man runs any command for us, it will call setuid(getuid())) (getuid() returns the real user id).
   Because we are not the superuser process, this change can only change the effective user ID. We will have the following situation:
   Now when the man process runs, it uses our UID as its effective user ID. This means that we can only access files for which we have our own permissions. That is, it can safely execute any filter on our behalf.
   – real user ID = our user UID (will not be changed)
   – effective user ID = our user UID
   – saved set-user-ID = man’s user UID (will not be changed)
4. When filter is finished, man will call setuid(euid).
   Here, euid is the UID of the man user. (This ID is saved by man calling geteuid.) This call is OK because the setuid parameter is equal to the saved set-user-ID. (This is why we need saved set-user-ID). At this time we will have the following situation:
   – real user ID = our user UID (will not be changed)
   – effective user ID = man’s UID
   – saved set-user-ID = man’s user UID (will not be changed)
5. Since the effective user ID is man, now the man program can operate its own files.
   By using saved set-user-ID in this way, we can use additional permissions through the set-user-ID of the program file when the process starts and ends. However, during this period we were operating under our own authority. If we fail to switch back to saved set-user-ID at the end, we may retain additional permissions while we run.

Let’s take a look at what will happen if man starts a shell:

• The shell here is started by man using fork and exec.
• Because at this time the real user ID and effective user ID are both our ordinary user UIDs (see step3), so the shell has no other additional permissions.
• The started shell cannot access man's saved set-user-ID(man), because the shell's saved set-user-ID is copied from the effective user ID by exec.
• In the child process (shell) executing exec, all user IDs are our ordinary user IDs.

Actually, the way we describe how man uses the setuid function is not particularly correct, because the program may set-user-ID to root. At this time, setuid will change all three uids into the id you set, but we Only the effective user ID needs to be set.

The above is the detailed content of Basic principles of Linux permission control. For more information, please follow other related articles on the PHP Chinese website!