Shulou(Shulou.com)06/01 Report--

This article mainly introduces "what is the principle of Linux permissions". In daily operation, I believe many people have doubts about what the principle of Linux permissions is. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubts of "what is the principle of Linux permissions?" Next, please follow the editor to study!

Security model

In the Linux system, all our operations are essentially the operation of the process to access the file. We need to get the appropriate access rights to access the files, and the access rights 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:

The original security model on Linux system is called DAC, whose full name is Discretionary Access Control, which is translated as autonomous access control.

Later, a new security model is designed, called MAC, whose full name is Mandatory Access Control, which is translated as mandatory access control.

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

To distinguish between the two, we call the Linux system that supports MAC SELinux, indicating that it is a security hardening system for Linux.

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

DAC security model

The core content of DAC is that in Linux, a process theoretically has the same permissions as the user who executes it. All the contents involved are carried out 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 changes through / etc/shadow, 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 name as its UID.

For / etc/passwd, each record field is user name: password (encrypted in / etc/shadow): UID:GID (default UID): description Note: home directory: log in to shell (the first program to run)

For / etc/group, each record field is the group name: password (usually no group password exists): GID: group member user list (comma-separated user UID list)

For / etc/shadow, each record field is: login name: encrypted password: last modified time: minimum time interval: maximum time interval: warning time: inactive time:

Give an example

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

File permission control information

File type

Files in Linux have the following types:

Ordinary files, including text files and binary files, can be created with touch

Socket file, used for network communication, usually created indirectly by the application during execution

The pipe file is a named pipe, not an unnamed pipe, which can be created with mkfifo

Character files and block files are both device files and can be created with mknod

Linked files are soft-linked files, not hard-linked files, and can be created with ln.

Access control group

Divided into three groups for control:

User contains permissions set for the owner of the file

Group contains permissions set on file group

Others contains permissions set for others

Configurable permissions

The following are common (but not all) permission values, including:

R indicates read permission.

W indicates write permission.

X is generally for executable files / directories, indicating that you have execute / search permissions.

S is generally for executable files / directories, indicating that you have the permission to give the file a primary permission, which can only be set by the user and group groups.

T generally for the directory, after setting the stickiness bit, users with permission can only write and delete their own files, otherwise they can write and delete all files in the directory. The old system also indicated that the text was copied to the exchange area to speed up after the executable file was run.

Give an example

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

For example

In the output, the 1st character represents the file type, where the normal file (-), the directory file (d), the socket file (s), the pipe file (p), the character file (c), the block file (b), and the linked file (l); the-rwxr-xr-x section starting with the second character represents the permission bit of the file, with a total of 9 digits.

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

The rwx in bit 2-4 indicates that the file can be accessed by its owner (owner) with r or w or x privileges.

The rmurx of bit 5 / 7 indicates that the file can be accessed by users in the same group as the file with the permission of r or x

The rmurx of bit 8-10 indicates that the file can be accessed by other unknown users with the privileges of r or x.

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

The permissions for each permission control group are represented by an one-bit octal; for example, 755 represents rwxr-xr-x.

The sforme t permission replaces the x position display; to set the sfort permission, you need to append the number before the corresponding octal access control group used to control the rforce wjournal x; the s permission is used for the master group control, and t for other controls.

Set the owner s to append 4, set the group s to append 2, and set other t permissions to append 1; for example, to set t in the front face of test/, use 1775 to represent rwxrwxr-t.

Process privilege control information

Process permissions

For processes, the following properties are related to file access:

Effective user id: the UID related to the permissions of the process to access the file (abbreviated as euid).

Effective group id: the GID related to the permissions of the process to access the file (abbreviated as egid).

Real user id: the UID of the user who created the process when logging in to the system (abbreviated as ruid).

Real group id: the GID of the user who created the process when logging in to the system (abbreviated as rgid).

Saved set user id: copied from euid.

Saved set group id: copied from egid.

Give an example

We can use ps and top to choose to view processes with euid and ruid. Or check the euid and ruid of the process through top

Examples viewed through top:

First enter top to get something like this

Here, the refresh frequency of the top is extended by the-d option for ease of operation. As you can see here, there is only the USER field, which represents the effective user id of the corresponding process.

Turn on the display options for read user id:

a. While the top command is running, type f, and you can see lines similar to the following:

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

c. Finally, enter Return and return to top, and you can see the options for real user id. Enter o at this time to adjust the column order. Finally, we can see that the output containing effective user id and real user id is as follows:

Access control policy for processes to access files

Rules

General permission control policy for process access to files

For the process to access the file, the most important thing is euid, so its permission attribute is 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 has the permissions set by the file user permission bit.

The control rules for group permissions egid are similar.

Modify permission properties by executing files through exec

When calling an executable file through exec:

The process ruid value is always the same

Saved set-user ID always comes from euid

The euid value depends on whether the set-user-ID bit of the file is set.

As follows:

Modify permission attributes through setuid (uid) system call

When modifying permission properties through setuid (uid):

Superuser can modify ruid, euid, saved set-user ID smoothly.

Unprivileged user can only modify euid when uid is equal to ruid, the other cannot be modified.

Give an example

Let me cite a few more special examples:

Set-user-id is set up

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

The rws of bit 1-3 indicates that the file can be accessed by its owner (owner) with r or w or s permissions

The rmurx in bit 4 / 6 indicates that the file can be accessed by users in the same group as the file with the privileges of r or x.

The rmurx in bit 7 / 9 indicates that the file can be accessed by other unknown users with the privileges of r or x.

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

When the ordinary user process executes the sudo command, it obtains the execution permission through the x in its others, and then through the s in user, the ordinary user process temporarily has the permission of the sudo executable file owner (root), that is, super permission.

This is why it is possible for ordinary users to execute many commands with administrator privileges through the sudo command.

Stick-bit is set up

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

If the sticky bit is not set in the directory, anyone who has write access to the directory can delete any of the files and subdirectories, even if he is not the owner of the corresponding file, he does not have read or write permission; after setting the sticky bit, 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 only write and delete files or directories they own.

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

Man programs can be used to display online help manuals, and man programs can be installed to specify set-user-ID or set-group-ID as a specified user or group.

Man programs 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 that contains the displayed man man pages.

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

The main line to grasp: when only man is executed, the process privilege is the privilege of the man user. When the child process is executed through man (such as through! bash leads to the shell command), the user switches to the current user, and then switches back.

The process is as follows:

Suppose the man program file is owned by user man and its set-user-ID bit has been 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

The man program accesses the required configuration files and man man pages. These files are owned by man users, but because effective user ID is man, access to the files is allowed.

When man runs any command for us, it calls setuid (getuid ()) (getuid () returns real user id). Because we are not a superuser process, this change can only change effective user ID. We will have the following situation: now the man process runs with our UID as its effective user ID. That is to say, we can only access files that we have our own permissions. That is, it can safely execute any filter.- real user ID on our behalf = our user UID (will not be changed)-effective user ID = our user UID- saved set-user-ID = man user UID (will not be changed)

When filter is done, man will call setuid (euid). Here, euid is the UID of the man user. (the ID is saved by calling geteuid through man.) this call is possible because the parameters of setuid and saved set-user-ID are equal. That's why we need saved set-user-ID. At this point 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)

Because effective user ID is man, the man program can now manipulate 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 at the beginning and end of the process. However, in the meantime, we are running under our own authority. If we cannot switch back to saved set-user-ID in the end, we may retain additional permissions while we are running.

Let's take a look at what happens if man starts a shell:

The shell here is started by man using fork and exec.

Because real user ID and effective user ID are our regular user UID (see step3), shell has no additional permissions.

The launched shell cannot access man's saved set-user-ID (man) because shell's saved set-user-ID is copied from effective user ID by exec.

In the child process (shell) that executes exec, all user ID are our ordinary user ID.

In fact, the way we describe man using the setuid function is not particularly correct, because the program may set-user-ID as root. At this point, setuid will turn all three uid into the id you set, but we only need to set effective user ID.

At this point, the study on "what is the principle of Linux permissions" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.