2. The "SELinux Learning notes" concept

1. Mandatory type of security contextin SELinux, the access control property is called the security context. Regardless of whether the subject or object has a security context associated with it, the security context is usually made up of three parts: User: Role: type. such as:$id-Zjoe:user_r:user_tin SELinux, the object or subject of an access control attribute has a context attribute on the association, because the type identifier in the security context determines the access rights in SELinux based on the type coercion policy. Note! SELinux is based on the labeling of Linux, also means that the subject to access the subject, to meet the traditional Linux rights control Ugo model and SELinux type enhancement strategy. In the security context, the type of a process (principal) is often referred to as a domain, so the domain, domain type, principal type, and process type are all meant to be. With respect to objects, user and role identifiers are seldom used, and for ease of management, the role of the object is usually defined as object_r.
2. Type Mandatory access controlin SELinux, all access must be explicitly authorized, Selinx does not allow any access by default, regardless of the current UGO structure, that is, regardless of the user/group ID. This means that there are no super users here. So what if the subject needs access to the object? in SELinux, it is common to use the Allow rule to specify the subject type (that is, the domain) to grant access to the object type, that is, the Allow rule specifies which types of processes can access which objects. The Allow rule consists of four parts:

• Primitive Type (Source type (s)) principal type, that is, domain
• Object Type (target type (s))
• Object Category (object Class (ES)) object category, such as file, directory, etc.
• License (Permission (s)) the subject can perform what operations on the object, which we call the access vector

Figure 1An example of the underlying syntax for the TE allow rule, such as:allow user_t bin_t:file {Read execute getattr};//domain-user_t processes can have read permissions, executable permissions, and permission to obtain the properties of a file of the object type bin_t. The properties of the obtained file are GetAttr we can understand to see the file's creation date, update time and other properties, as well as DAC access mode (RWX).
3. Example of type enforcement policyIn order to further study the type enforcement strategy, we take an example of the program for managing passwords (passwd) for an in-depth understanding that in Linux, the passwd program is trusted to modify the shadow password file (/etc/shadow) that stores the encrypted password, passwd The program executes its own internal security policy, allowing ordinary users to modify their own passwords and allow ROOT to Modify all passwords. Therefore, the passwd program needs to have the ability to move and recreate the shadow file, which of course has the right in standard Linux, because the passwd program executable is added setuid bit when executed, and it acts as root The user (which can access all files) allows ( we know, in the system we want to modify a user's password, the root user and the ordinary user can use/USR/BIN/PASSWD someuser This command to modify this/etc/passwd this file, The root user has the Write permission to the/etc/passwd, it is understandable that the ordinary user, where the role of Setuid,setuid is "let the user who executes the command to execute the command owner's permission to perform", Is that ordinary users will have root permissions when executing passwd, so you can modify the/etc/passwd file. ). This means that any program (when run as root) is likely to be able to modify the shadow file. What type coercion allows us to do is to make sure that only the passwd program (or similar trusted program) can access the shadow file, regardless of who is running the program. Describes the process by which the passwd program uses the type coercion policy in the SELinux system:
Figure 2The passwd domain type-passwd_t is defined, and the type of shadow password file is-shadow_t. Then the Allow rule means that the passwd process with the authorization domain type of passwd_t has access to the file type shadow_t file Shadow, and has moved and created a new shadow password file. The security context for the corresponding Shadow is as follows:

# ls-z/etc/shadow- r----root root system_u:object_r:shadow_t shadow

At this point, under the current policy, check the security context of the process running the password and program as follows:

# Ps-az joe:user_r:passwd_t 16532 pts/0 00:00:00 passwd

4. Domain ConversionsWhat we do on the surface seems to be simply that the subject provides permission to object access to write a TE strategy. Because we have to consider the following problem, for example, in a Linux system, user Joe logs into the system and creates a shell process such as bash. The type of shell process, however, is user_t, which represents a common, untrusted user process domain type. So how does the Joe user let the shell process change the password at this point? First we look at:
Figure 3
when Joe's shell program runs another program, the new process inherits the user_t domain type, and user_t is an untrusted domain, so first we should not have a domain type of user_ The process of T directly operates the shadow password file because it allows other programs to read and write to this very critical file. So how do we do that at this point? That is, how to implement a shell process that transforms a domain into a user_t domain into a passwd_t process.

①setuid Traditional Linux, we can give passwd a value of setuid by assigning it root privileges. In a traditional Linux system, use the following command to view the passwd file information:

# ls-l/usr/bin/passwd

-r- s xx 1 root root 19336 Sep 7 04:11/usr/bin/passwd

Figure 4    From what we can see setuid in traditional Linux is a very powerful feature, but also burst out of the main weakness of traditional Linux, that passwd need to run as root access shadow files, However, when running as root, passwd can access all of the system resources, and our original purpose is only to need passwd operation shadow file, which not only violates our original intention, but also violates the principle of least privilege. ②te     We know from Figure 2 that the Allow rule ensures that the passwd process in the passwd_t domain can access the shadow password file, so how does the user_t to passwd_t domain transition be implemented? , see:
Figure 5 from which we can see that there are four types: user_t (Shell), shadow_t (Shadow), passwd_t (passwd), passwd_exec_t (passwd). The security context for passwd is as follows:

# ls-z/usr/bin/passwd

-r-sxx root root system_u:object_r:passwd_exec_t/usr/bin/passwd

from the above information we can create the TE policy rule is to run the passwd_t domain, first the first rule:

Allow

user_t passwd_exec_t:file {getattr execute}; Allow the domain to be usert_ (this is the shell process) and start the EXECVE () system call in the passwd executable (passwd_exec_t). This actually means that the shell process is allowed to call EXECVE () to execute passwd.

Rule number two:

Allow

passwd_t passwd_exec_t:file entrypoint; Provides access to the passwd_t domain, and the entrypoint license is a permission in Selinxu that defines which executable (such as passwd) can run in a specific domain (passwd_t), which is called domain transformation . The passwd executable file in the example is identified as passwd_exec_t, and the passwd_t type has entrypoint access passwd_exec_t, then passwd has the condition to run in the passwd_t domain type.

Rule three:

Allow

user_t passwd_t:process transition; There is no access to the object in this rule, because the object is a process, which means that the object at this time represents the course. If the system resources are encapsulated as objects, then the process can also be understood as system resources, where the process as the object is not contradictory. In this rule, the license is transition, and the meaning of this license is to allow the modification of the type in the security context of the process. The meaning of this rule, then, is to allow the user_t domain to be transformed into a passwd_t domain.

So here we understand the process of domain transformation, that is to say, a successful domain transition, these three rules must be guaranteed to exist at the same time, and when the three licenses in a TE policy at the same time to complete the domain transformation. Summarized as follows:

1. The new domain of the process (passwd_t) has a entrypoint license to the executable (passwd)
2. Process current domain (usr_t) has execute permission on the ingress file (passwd_exec_t)
3. Process current domain (usr_t) has transition license for new domain (passwd_t)

5. Default Domain transition: type_transition directive through the previous understanding that we already know the process of domain transformation, then there is a doubt that user Joe how to identify the domain transformation it needs, usually we do not need users to explicitly make these requests,    This requires a way for the system to start the domain transition by default. To support the default domain transitions, here we introduce a new rule, the Type transition rule (type_transition). This rule provides a way for SELinux policy to specify the default domain transition, as follows:

type_transition user_t passwd_exec_t : Process passwd_t;//turn the main user_t domain into a principal passwd_t domain

This syntax rule field allows different rules, but you can still see the familiar subject and object domains (user_t and passwd_exec_t), as well as the object category (process), and the new domain (passwd_t).
6. Role SELinux also provides a role-based access control (rbac:role-based access controls). The promising substitution of RBAC as a traditional access control (DAC autonomous access, MAC forced access) has received wide attention. RBAC supports three well-known security principles: the principle of least privilege, the principle of separation of responsibilities, and the principle of data abstraction, and SELinux's RBAC feature is built on TE because access control in SELinux is primarily implemented by type, A role is a type that restricts the types of processes that can be transformed based on the role identifiers in the process security context. So how do you define the limitations of roles? See:
As we can see in Figure 6, the role section (USER_R) is added here, and the statement defining a role is as follows:

The role

user_r type Passwd_t;//role statement declares the character identifier as well as the declared role-related types. This declares the role User_r and the associated type passwd_t, which means that the passwd_t type coexists with the role User_r in the security context, and without this role statement, a new security context joe:user_r:passwd_t cannot be created. and the Execve () function call will also fail, and a timely TE policy allows Joe's type (user_t) to have all access rights.

7.MLS (multi-level security) MLS is optional for SELinux, but despite this, MLS has enhanced some security for some applications. So in order to support MLS, the security context is extended as follows, adding security levels such as:

User:role:type:sensitivity[:category,...] [-sensitivity[:category,...]]

The security context that contains the MLS has at least one security level, and if there are two security levels, then the two security levels are called low and high, and if the high security level is lost, then only the low security level takes effect.
8.SELinux Features

①.permissive (license) mode SELinux can run in Permissive mode, in which only access checks are present but no disallowed access is denied. The simplest way to check the current working mode of SELinux is to run the Getenforce command. To set the system SELinux operating mode, you can use Setenforce 0 to set to permissive mode, use Setenforce 1 to modify to force mode, but if you modify from permissive mode to mandatory mode, you need to log in as root and then operate. ②PASSWD example to help us better understand domain transformations, let's verify the domain transformation using the following process:

• To start the first terminal, run the passwd command:

$ passwdchanging password for user Joe. Changing password for Joe (current) UNIX password:

• Start the second terminal, Su to the root user, and then use the following command for fear of death:

$ su
Password:
Your default context is root:sysadm_r:sysadm_t.
Does want to choose a different one? N
# PS Axz|grep passwd
user_u:user_r:passwd_t 4299 pts/1 s+ 0:00 passwd

at this point we see that the domain of the passwd process is passwd_t.

③ Policy Analysis tool Apol This is a very useful tool for checking policy content, developed by Tresys Technology, and released with the SELinux Toolkit as a setools. The Setools package is included in most SELinux release packages and runs the Apol command to determine if the tool is installed on the system, and if no Apol (Analyze policy) is installed, is a mature selinux policy analysis tool, SELinux policies are also frequently used in this series of articles. If we want to use it to check the policy file, run Apol and open the strict policy file, you can see the policy-related summary information under Query>policy Summary.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

2. "SELinux Learning Notes" concept