SELinux (security enhanced Linux) is the implementation of mandatory access control by the National Security Administration (NSA), which is the most outstanding new security subsystem in the history of Linux. NSA developed an access control system with the help of the Linux community. Under the restriction of this access control system, a process can only access the files needed in its tasks. SELinux is installed on Fedora and Red Hat Enterprise Linux by default, and can also be used as an easy to install package on other distributions.
SELinux is a mandatory access control (MAC) system provided in the 2.6 Linux kernel. SELinux is the most comprehensive and fully tested Linux security module available at present. It is built on the basis of 20 years of MAC research. SELinux combines multi-level security or an optional multi class policy in the type enforcement server, and adopts the concept of role-based access control. 
Most people who use SELinux use SELinux ready distributions, such as Fedora, Red Hat Enterprise Linux (RHEL), Debian, or CentOS. They both enable SELinux in the kernel, provide a customizable security policy, and provide many user level libraries and tools, all of which can use the functions of SELinux.
SELinux is a domain type based MAC security system. It is written by NSA and designed as a kernel module included in the kernel. Some security related applications are also patched with SELinux. Finally, there is a corresponding security policy. Any procedure has full control over its resources. If a program is going to throw a file with potentially important information into the / tmp directory, no one can stop it in the case of DAC. SELinux provides better access control than traditional UN IX permissions.
The main value SELinux brings to Linux is to provide a flexible and configurable MAC mechanism.
Security enhanced Linux (SELinux) consists of the following two parts:
1) Kernel SELinux module (/ kernel / security / SELinux)
2) User tools
SELinux is a security architecture, which is integrated into Linux kernel 2.6. X through LSM (Linux security modules) framework. It is a joint project of NSA (United States National Security Agency) and SELinux community.
SELinux provides a flexible MAC system, which is embedded in Linux kernel. SELinux defines the access and transformation permissions of each user, process, application and file in the system. Then it uses a security policy to control the interaction between these entities (user, process, application and file). The security policy specifies how to check strictly or loosely.
SELinux is transparent to system users. Only system administrators need to consider how to make strict policies in their servers. Strategies can be strict or loose as needed.
Only when the standard Linux access control and SELinux access control are met can the subject access the object.
1.1 key differences between DAC and MAC (root user)
Security enhanced Linux (SELinux) is a set of core components and user tools started by NSA (National Security Administration) and added to Linux system. It can let applications run on the minimum permissions required. The unmodified Linux system uses autonomous access control. Users can request higher permissions themselves, so malware can access almost any file it wants to access. If you grant root permission, it can do anything.
There is no concept of root in SELinux. The security policy is defined by the administrator, and no software can replace it. This means that the damage caused by potential malware can be minimized. In general, SELinux is only used by enterprise users who are very concerned about data security.
The operating system has two types of access control: independent access control (DAC) and forced access control (MAC). Standard Linux security is a DAC, SELinux adds a flexible and configurable MAC for Linux.
All DAC mechanisms have a common weakness, that is, they can’t recognize the basic difference between natural person and computer program. Simply put, if a user is authorized to access, it means that the program is also authorized to access. If the program is authorized to access, then the malicious program will have the same access. The fundamental weakness of DAC is that the main body is vulnerable to a variety of malware attacks. MAC is the way to avoid these attacks. Most MAC features constitute a multi-layer security model.
SELinux implements a more flexible form of MAC called type enforcement and a non mandatory multi level security.
In Android 4.2, SELinux is an option, and Google does not directly revoke root or other functions. This is an option for enterprise users or users who attach great importance to privacy data, and ordinary consumers can completely turn it off.
2. Operation mechanism of SELinux
SELinux’s decision-making process is shown in the following figure:
When a subject (such as an application) tries to access an object (such as a file), the policy execution server in the kernel will check the AVC (access vector cache). In the AVC, the permissions of subject and object are cached. If the decision cannot be made based on the data in AVC, the security server is requested to look up the security environment of “application + file” in a matrix. Access is then allowed or denied based on the query results, with the denial message details in / var / log / messages.
3. SELinux pseudo file system
/The kernel subsystem of SELinux / pseudo file system usually uses commands similar to / proc / pseudo file system. System administrators and users do not need to operate this part. /An example of SELinux / directory is as follows:
The code is as follows:
dr-xr-xr-x 1 root root 0 Sep 22 13:14 booleans
–w——- 1 root root 0 Sep 22 13:14 commit_pending_bools
-rw-rw-rw- 1 root root 0 Sep 22 13:14 context
-rw-rw-rw- 1 root root 0 Sep 22 13:14 create
–w——- 1 root root 0 Sep 22 13:14 disable
-rw-r–r– 1 root root 0 Sep 22 13:14 enforce
-rw——- 1 root root 0 Sep 22 13:14 load
-r–r–r– 1 root root 0 Sep 22 13:14 mls
-r–r–r– 1 root root 0 Sep 22 13:14 policyvers
-rw-rw-rw- 1 root root 0 Sep 22 13:14 relabel
-rw-rw-rw- 1 root root 0 Sep 22 13:14 user
For example, cat enforcemay have the following values:
1： enforcing mode
0： permissive mode
4. SELinux configuration file
The SELinux configuration file or policy file is located in the / etc / directory.
4.1 / etc / sysconfig / SELinux configuration file
/Etc / sysconfig / SELinux is a symbolic link. The real configuration file is / etc / SELinux / config
SELinux can be configured in two ways:
1) Using the configuration tool: security level configuration tool (system config SELinux)
2) Edit the configuration file (/ etc / sysconfig / SELinux)
/The following configuration options are included in etc / sysconfig / SELinux:
1) Turn SELinux on or off
2) Set which policy the system executes
3) Set how the system executes the policy
4.2 profile options
SELinux = forcing|permission|disabled – define the advanced state of SELinux
• enforcing — The SELinux security policy is enforced.
• permissive — The SELinux system prints warnings but does not enforce policy.
• disabled — SELinux is fully disabled. SELinux hooks are disengaged from the kernel and the pseudo-file system is unregistered.
4.2.2 selinuxtype (Security Policy)
Selinuxtype = targeted|strict – specifies which policy SELinux executes
• targeted – only the daemons of the target network are protected. Whether or not each daemon executes the policy can be configured through system config SELinux. Protect common network services as SELinux default.
You can use the following tools to set the Boolean value for each of the daemons:
1) Getsebool – A: lists all Boolean values for SELinux
2) Setsebool: set SELinux Boolean value, for example: setsebool – P dhcpd_disable_trans = 0, – P means that it is still valid after reboot is used.
• strict – performs full protection for SELinux. Define the security environment for all subjects and objects, and each action is handled by the policy execution server. Provide a role-based access control (RBAC) – compliant policy with complete protection functions to protect network services, general instructions and applications.
Setlocaldefs = 0| 1 – controls how local definitions are set (users and Booleans).
• 1: these definitions are controlled by load ﹣ policy, which comes from the file / etc / SELinux / < policyname >
• 0: controlled by semanage
4.3 / etc / SELinux / directory
/Etc / SELinux / is the directory where all policy files and main configuration files are stored. Examples are as follows:
The code is as follows:
drwxr-xr-x 5 root root 4096 Sep 22 17:27 strict
drwxr-xr-x 5 root root 4096 Sep 22 17:28 targeted
5. SELinux tools
1) / usr / SBIN / setenforce – modify SELinux operation mode, as follows:
• setenforce 1 – SELinux runs in enforced mode
• setenforce 0 – SELinux runs in warning (permission) mode
To shut down SELinux, you can modify the configuration file / etc / SELinux / config or / etc / sysconfig / SELinux
2) / usr / SBIN / sestatus – V – displays the detailed status of the system, as follows:
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 21
Policy from config file: targeted
Current context: user_u:system_r:unconfined_t:s0
Init context: system_u:system_r:init_t:s0
3) / usr / bin / newRole – run a new shell in a new context or role
4) / SBIN / restorecon – sets the security environment for one or more files by marking extended properties for the appropriate file or security environment
5) / SBIN / fixfiles – check or correct the security environment database in the file system
6) Getsebool – getsebool – A: view all Boolean values
7) Setsebool – parameter – P, permanent setting
8) Chcon modify the security context of files and directories
Chcon – r recursion
6. Type enforcement security context
Security context is a simple and consistent access control attribute. In SELinux, type identifier is the main component of security context. Due to historical reasons, the type of a process is usually called a domain. The meaning of “domain” and “domain type” is the same. We don’t need to distinguish or avoid the use of term domain. Generally, we think that [domain] Domain type, principal type and process type are all synonymous, that is, they are all “types” in the security context.
SELinux has modified many of the commands in the system to display the security context of the object and principal by adding a – Z option.
1) According to the PAM ﹣ selinux.so module of PAM subsystem, the system sets the security context for the login to run the program;
2) The security content rules of the file are as follows:
• RPM package installation: security context will be generated according to the records in RPM package;
• files created manually: the security context will be set according to the policy;
• CP: regenerates the security context;
• MV: the security context does not change.
3) id -Z
Shows the security context of your shell;
4) ps -Z
Check the security context of the process;
5) ls -Z
Check the security context of files and directories;
6.1 security context format
All operating system access control is based on some type of access control attribute of the associated object and subject. In SELinux, access control properties are called security contexts. All objects (files, inter process communication channels, sockets, network hosts, etc.) and subjects (processes) have their associated security context. A security context consists of three parts: user, role and type identifier. Security context is often specified or displayed in the following format:
The user and role identifiers in the security context have little impact on the type mandatory access control policy except for a little constraint on the enforcement. They are more meaningful for processes, users and role identifiers, because they are a combination of control types and user identifiers, which will be associated with Linux user accounts; however, for objects, users and role identifiers Identifier is rarely used. In order to standardize management, the role of object is often object_r, and the user of object is often the user identifier of the process of creating object. They have little effect on access control.
The difference between user ID in standard Linux security and user identifier in security context. Technically speaking, they are orthogonal identifiers, which are used for standard and security enhanced access control mechanisms respectively. Any correlation between them is strictly regulated by the login process according to the specification, rather than directly enforced by SELinux policy.
1) User identity: similar to the uid in Linux system, it provides identity recognition to record identity; part of security context;
2) Three common users:
• user: the default of ordinary users after logging in the system;
System: the preset of system process during startup;
Root: default after root login;
3) Users are not very important in targeted policy;
4) In strict policy, it is important that all default SELinux users end with “_”, except root.
1) Roles of files, directories and devices: usually object_r;
2) The role of a program: usually system;
3) User’s role: targeted policy is system ﹣ strict policy is sysadm ﹣ staff ﹣ user ﹣ user’s role, similar to GID in the system, different roles have different permissions; users can have multiple roles; but only one role can be used at the same time
4) Use strict and MLS policies based on RBAC (roles based access control) to store role information
1) Type: it is used to divide subject and object into different groups, define a type for each subject and object in the system, and provide the lowest permission environment for process operation;
2) When a type is associated with an executing process, its type is also called domain;
3) Type is the most important part of SELinux security context, and it is the heart of SELinux type enforcement. The default value is “U T”;
Level and category: define levels and categories, only for MLS strategy
• level: represents the security level. At present, the defined security level is s0-s15, which is getting higher and higher
• category: represents classification, and the currently defined classification is c0-c1023
6.2 comparing SELinux and standard Linux access control attributes
In standard Linux, the access control attribute of the subject is the real and effective user and group ID associated with the process through the process structure in the kernel. These attributes are protected by the kernel using a large number of tools, including the login process and setuid program. For the object (such as file), the inode of the file includes a set of access mode bits, file user and group ID. The previous access control is based on the three control bits of read / write / execute, with one set for the file owner, the group to which the file owner belongs, and the other.
In SELinux, the access control attribute is always in the form of a three person security context (user: role: type). All objects and subjects have an associated security context. In particular, because SELinux’s main access control feature is type coercion, the type identifier in the security context determines access.
Note: SELinux adds Te: type enforcement on the basis of standard Linux, which means that both standard Linux and SELinux access control must be able to access an object first. For example, if we have SELinux write permission for a file, but we do not have w permission for the file, then we cannot write the file. The following table summarizes the comparison of access control attributes between standard Linux and SELinux:
|Process security properties||Real and valid user and group IDs||Security context|
|Object security attribute||Access mode, file user and group ID||Security context|
|Access control foundation||Access mode for process user / group ID and file,
File based user / group ID for this access mode
|In process type and file type
Permission allowed between
1) In the system, each file, directory, network port, etc. is assigned a security context, and policy gives the rules of the security context.
2) SELinux determines whether the access behavior can be executed according to the policy and security context rules;
3) Subject: system process, such as / usr / SBIN / httpd;
4) Object: the accessed items, such as file, directory, IP, socket, etc;
7. Type enforcement (TE) access control
In SELinux, all access must be explicitly authorized. SELinux does not allow any access by default, regardless of the Linux user / group ID. This means that there is no default super user in SELinux. Unlike root in standard Linux, the allow rule is used to grant access rights by specifying the subject type (i.e. domain) and object type. The allow rule consists of four parts:
• source type (s) is usually the domain type of the process you are trying to access
• target type (s) the type of object accessed by the process
• object class (ES)) specifies the type of object that is allowed to be accessed
• permission (s) symbolizes the type of access the target type allows the source type to access the object type
The code is as follows:
This example shows the basic syntax of the te allow rule, which contains two type identifiers: the source type (or subject type or domain) user_t, and the target type (or object type) bin_t. The identifier file is the object class name defined in the policy (in this case, it means a normal file)
Processes with the domain type user? T can read / execute or get properties of file objects with the bin? T type.
SELinux allow rules like the previous examples are actually granted access in SELinux. The real challenge is how to ensure that tens of thousands of access are authorized correctly, only the necessary permissions are granted, and achieve the security as much as possible.
7.1 setuid program in standard Linux Security
Joe, a proficient user, wants to modify the existing password problem safely. The way for Linux to solve this problem is to assign a setuid value to passwd so that it has root permission when executing. If you list the password file on a common Linux system, you will see:
The code is as follows:
-rwsr-xr-x. 1 root root 41292 Sep 7 2012 /usr/bin/passwd
Note two things here. The first one is that the x position of the owner’s permission is set to s, which is the so-called setuid bit, which means that any process executing this file will change its effective uid (i.e. user ID) to the file owner. Here, root is the file owner, so when executing the password program, it will actually run with the root user’s ID. The execution process is shown as follows:
From the above analysis, it can be seen that passwd runs as root and can access any resources of the system, which brings security problems to the system. In fact, it only needs to access shadow and its related files. And shadow only needs to be accessed by passwd. This is not possible in standard Linux, and te (type coercion) does it.
8. Role based access control
SELinux also provides a role-based access control (RBAC). The RBAC feature of SELinux is established by type coercion. The access control in SELinux is mainly implemented by type. The role restricts the types that the process can transform based on the role identifier in the process security context. In this way, the policy writer can create a role and allow it to transform into a set of domain classes Type (assuming that the type enforces the rule to allow transitions) to define the limits of the role.
9. Multi level security in SELinux
Type coercion Enforcement) is undoubtedly the most important MAC mechanism introduced by SELinux. However, in some cases, it is mainly a subset of security control applications. The traditional MLS MAC is more valuable when used together with type enforcement. In these cases, SELinux always includes some form of MLS function, and MLS feature is optional. In SELinux Of the two MAC mechanisms, it is usually not the most important one. For most secure applications, including many unclassified data applications, type enforcement is the most appropriate mechanism for security enhancement. Nevertheless, MLS enhances security for some applications.
In most SELinux policies, sensitivity (S0, S1,…) and category (C0, C1,…) use generic names, leaving it to user space programs and libraries to specify meaningful user names. (for example: S0 may be associated with unclassified, S1 may be associated with secret)
In order to support MLS, the security context has been extended to include security levels, such as:
The code is as follows:
Examples are as follows:
The code is as follows:
LABEL PID TTY TIME CMD
unconfined_u:system_r:insmod_t:s0-s0:c0.c255 4940 pts/0 00:00:00 passwd
Note that the MLS security context must have at least one security level (it consists of a single sensitivity and 0 or more categories), but it can include two security levels, which are called low (or process trend) and high (or process gap), respectively. If the high security level is lost, it will be considered the same as the low security level (the most common case), In fact, for the object and process, the low and high security levels are usually the same, and the level range commonly used for the process is considered as the trusted subject (i.e. process trust degradation information) or multi-layer object, such as a directory, which also includes objects of different security levels. For simplicity, assume that all processes and objects have only one level of security.
10. Policy analysis tool apol
The apol (analyze policy) tool is a mature SELinux policy analysis tool, which is located in the setools toolkit. Use it to open the policy.xx file to analyze all related policies. XX is the version number of the policy compiler (checkpolicy).
SELinux access control is based on the security context associated with all system resources (including processes), which includes three components: user, role and type identifier. Type identifier is the main foundation of access control.
In SELinux, the main feature of access control is type coercion. Between the subject (i.e. process) and the object, access is authorized by specifying the allow rule (the type of subject (also called domain type) is the source, and the type of object is the target). Access is granted to specific object classes, and fine-grained permission is set for each object class.
A key advantage of type coercion is that it can control which program may run on a given domain type. Therefore, it allows access control to a single program (much safer than user level security control). To make a program run in another domain (i.e. running in a given process type) is called domain transformation, which is tightly controlled by SELinux’s allow rule , SELinux also allows domain transformation to occur automatically through the type ﹣ transition file.
SELinux does not directly use role identifiers in the context of access control security. On the contrary, all accesses are type-based. Roles are used to associate allowed domain types. In this way, the functions of type forced permission can be set together to authenticate users as a role.
SELinux provides an optional MLS access control mechanism, which provides more access restrictions. MLS features are built on te mechanism. MLS extends the content of security context, including a current (or low) security level and an optional high security level.