Detailed explanation of SELINUX working principle

1. Introduction

The main value that SELinux brings to Linux is: providing a flexible and configurable MAC mechanism.

Security-Enhanced Linux (SELinux) consists of two parts:

1) Kernel SELinux module (/kernel/security/selinux)

2) User-mode tools

SELinux is a security architecture that is integrated into the Linux Kernel 2.6.x through the LSM (Linux Security Modules) framework. It is a joint project of NSA (United States National Security Agency) and SELinux community.

SELinux provides a flexible mandatory access control (MAC) system and is embedded in the Linux Kernel. SELinux defines the access and change permissions for each user, process, application, and file in the system, and then uses a security policy to control the interactions between these entities (users, processes, applications, and files). The security policy specifies how to strictly or loosely check.

SELinux is transparent to system users, and only the system administrator needs to consider how to formulate strict policies in his server. Policies can be as strict or as lenient as needed.

The subject can access the object only when both [Standard Linux Access Control] and [SELinux Access Control] are met.

1.1 The key difference between DAC and MAC (root user)

Security Enhanced Linux (SELinux) was originally launched by the NSA (National Security Agency) and added to the Linux system as a set of core components and user tools that allow applications to run with the minimum permissions they require. Unmodified Linux systems use discretionary access control, where users can request higher permissions themselves, so malware can access almost any file it wants, and if you give it root permissions, it can do anything.

There is no concept of root in SELinux. Security policies are defined by administrators and cannot be replaced by any software. This means that the damage that potential malware can cause can be kept to a minimum. Generally speaking, only enterprise-level users who attach great importance to data security will use SELinux.

There are two types of access control in operating systems: discretionary access control (DAC) and mandatory access control (MAC). Standard Linux security is a DAC, SELinux adds a flexible and configurable MAC to Linux.

All DAC mechanisms share a common weakness: they fail to recognize the most basic difference between natural persons and computer programs. To put it simply, 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 also have the same access rights. The fundamental weakness of DAC is that the subject is vulnerable to a wide variety of malware attacks. MAC is the way to avoid these attacks. Most MAC features form a multi-layer security model.

SELinux implements a more flexible MAC form called Type Enforcement and a non-mandatory multi-level security form.

In Android 4.2, SELinux is an optional feature, and Google did not directly cancel root permissions or other features. This is an option provided for enterprise-level users or users who attach great importance to privacy data. Ordinary consumers can completely turn it off.

2. SELinux operating mechanism

The SELinux decision process is shown in the following figure:

When a subject (e.g., an application) tries to access an object (e.g., a file), the policy enforcement server in the kernel will check the AVC (Access Vector Cache), where the permissions of the subject and object are cached. If no decision can be made based on the data in the AVC, a request is made to the security server, which looks up the security environment of the "application+file" in a matrix. Access is then allowed or denied based on the query results, with the denial message details located in /var/log/messages.

3. SELinux pseudo file system

/selinux/ pseudo file system kernel subsystem commonly used commands, it is similar to the /proc/ pseudo file system. System administrators and users do not need to operate this part. An example of the /selinux/ directory is as follows:

-rw-rw-rw- 1 root root 0 Sep 22 13:14 access 
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 enforce its value may be as follows:

1: enforcing mode

0: permissive mode

4. SELinux Configuration File

SELinux configuration files or policy files are 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

There are two ways to configure SELinux:

1) Use the configuration tool: Security Level Configuration Tool (system-config-selinux)

2) Edit the configuration file (/etc/sysconfig/selinux).
/etc/sysconfig/selinux contains the following configuration options:

1) Enable or disable SELinux

2) Set which policy the system executes

3) Set how the system executes the policy

4.2 Configuration File Options

4.2.1 SELINUX

SELINUX=enforcing|permissive|disabled — defines 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 SELinux policy to enforce

targeted — Only the targeted network daemons are protected. Whether each daemon executes the policy can be configured through system-config-selinux. Protect common network services. This is the default value for SELinux.

You can use the following tools to set the boolean value of each daemon:

1) getsebool -a: List all SELinux Boolean values

2) setsebool: Set the SELinux Boolean value, such as: setsebool -P dhcpd_disable_trans=0, -P means that it is still valid even after reboot.

• strict — Enforce full protection of SELinux. Defines the security context for all subjects and objects, and each Action is processed by the policy execution server. Provides policies that comply with Role-based-Access Control (RBAC) and have complete protection functions to protect network services, general commands, and applications.

4.2.3 SETLOCALDEFS

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. An example is as follows:

-rw-r--r-- 1 root root 448 Sep 22 17:34 config 
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, the example is as follows:

• setenforce 1 — SELinux runs in enforcing mode
• setenforce 0 — SELinux runs in warning (permissive) mode

To disable SELinux, you can modify the configuration file: /etc/selinux/config or /etc/sysconfig/selinux

2) /usr/sbin/sestatus -v — Displays detailed system status, as shown below:

SELinux status: enabled 
SELinuxfs mount: /selinux 
Current mode: enforcing 
Mode from config file: enforcing 
Policy version: 21 
Policy from config file: targeted 
Process contexts: 
Current context: user_u:system_r:unconfined_t:s0 
Init context: system_u:system_r:init_t:s0 
/sbin/mingetty system_u:system_r:getty_t:s0

3) /usr/bin/newrole — runs a new shell in a new context or role

4) /sbin/restorecon — Sets the security environment for one or more files by marking the appropriate files or security environments with extended attributes

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 changes the security context of files and directories

chcon –u [user]
chcon –r [role]
chcon –t [type]
chcon –R recursive

6. Type Enforcement Security Context

The security context is a simple, consistent access control attribute. In SELinux, the type identifier is the main component of the security context. For historical reasons, the type of a process is often referred to as a domain. "Domain" and "domain type" have the same meaning. We do not have to strictly distinguish or avoid using the term domain. Usually, we think that [domain], [domain type], [subject type] and [process type] are synonymous, that is, they are all "TYPE" in the security context.

SELinux modifies many commands in the system by adding a -Z option to display the security context of objects and subjects.

1) The system sets the security context for the program run by the logon user based on the pam_selinux.so module in the PAM subsystem;
2) The Security Context rules for the file are as follows:

• If the rpm package is installed, the security context will be generated according to the records in the rpm package;
• Manually created files: The security context is set according to the policy.
• cp: will regenerate the security context;
• mv: The security context remains unchanged.

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 controls are based on some type of access control attributes on the associated objects and subjects. In SELinux, access control attributes are called security contexts. All objects (files, inter-process communication channels, sockets, network hosts, etc.) and subjects (processes) have security contexts associated with them. A security context consists of three parts: user, role, and type identifier. The security context is usually specified or displayed in the following format:

USER：ROLE：TYPE[LEVEL[：CATEGORY]]

The user and role identifiers in the security context have little effect on the type-enforced access control policy except for a little constraint on enforcement. For processes, user and role identifiers are more meaningful because they are used to control the union of type and user identifiers, which are associated with Linux user accounts; however, for objects, user and role identifiers are rarely used. For standardized management, the role of an object is often object_r, and the user of an object is often the user identifier of the process that created the object. They have little effect on access control.

The distinction between user IDs in standard Linux security and user identifiers in security contexts is that, technically speaking, they are orthogonal identifiers used for standard and security-enhanced access control mechanisms, respectively, and any correlation between the two is strictly dictated by the logon process, rather than directly enforced by SELinux policy.

6.1.1 USER
1) User identity: Similar to UID in Linux system, it provides identity identification and is used to record identity; it is part of the security context;
2) Three common types of users:

• user_u : the default setting for ordinary users after logging into the system;
• system_u : The default setting of system processes during booting;
• root : default after root login;

3) Users are not very important in targeted policies;
4) It is more important in strict policy, all default SELinux Users end with "_u", except root.

6.1.2 ROLE

1) The role of files, directories, and devices: usually object_r;
2) The role of the program: usually system_r;
3) User role: targeted policy is system_r; strict policy is sysadm_r, staff_r, user_r; user role is similar to GID in the system, different roles have different permissions; a user 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

6.1.3 TYPE

1) type: used to divide subjects and objects into different groups, define a type for each subject and object in the system, and provide the lowest privilege environment for process operation;
2) When a type is associated with an executing process, its type is also called a domain;
3) type is the most important part of SELinux security context and the heart of SELinux Type Enforcement. The default value ends with _t.

LEVEL and CATEGORY: define levels and categories, only used in mls strategy

• LEVEL: represents the security level. The currently defined security levels are s0-s15, with increasing levels.
• CATEGORY: represents the category. The currently defined categories are c0-c1023

6.2 Comparing SELinux and Standard Linux Access Control Attributes

In standard Linux, the access control attributes of a subject are the real and effective user and group IDs associated with the process through the process structure in the kernel. These attributes are protected by the kernel using a number of tools, including login processes and setuid programs. For objects (such as files), the file's inode includes a set of access mode bits, the file's user and group IDs. Previous access control was based on the three control bits of read/write/execute, with one set for the file owner, one set for the group to which the file owner belongs, and one set for others.

In SELinux, access control attributes are always in the form of a security context triplet (user:role:type), and all objects and subjects have an associated security context. It is important to note that because the primary access control feature of SELinux is type enforcement, the type identifier in the security context determines access rights.

Note: SELinux adds type enforcement (TE) to standard Linux, which means that both standard Linux and SELinux access control must be satisfied to be able to access an object first. For example, if we have SELinux write permission for a file, but we do not have the w permission for that file, then we cannot write to that file. The following table summarizes the comparison of access control attributes between standard Linux and SELinux:

Standard Linux
SELInux

Process security attributes real and effective user and group ID
Security context

Object security attributes access mode, file user and group ID
Security context

Access control based on process user/group ID and file access modes,
This access mode is based on the user/group ID of the file
Permissions allowed between process types and file types

6.3 Summary

1) Each file, directory, network port, etc. in the system is assigned a security context, and the policy gives the rules for interaction between the security contexts.
2) SELinux determines whether access behavior is executable based on policy and security context rules;
3) Subject: system process, such as /usr/sbin/httpd;
4) Object: The item being accessed, such as File, Directory, IP, Socket, etc.

7. Type Enforcement (TE) Access Control

In SELinux, all access must be explicitly authorized, and SELinux does not allow any access by default, regardless of the Linux user/group ID. This means that in SELinux, there is no default superuser. Unlike the root in standard Linux, access rights are granted using allow rules 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 trying to access
• Target type(s) The type of object accessed by the process
• Object class(es) specifies the type of object to which access is allowed
• Permission(s) indicates the type of access that the target type allows the source type to access the object type.

Here are some examples:

allow user_t bin_t : file {read execute getattr};

This example shows the basic syntax of a 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 name of the object class defined in the policy (in this case, a regular file). The permissions enclosed in curly braces are a subset of the valid permissions for the file object class. This rule is interpreted as follows:

A process with domain type user_t can read/execute or get attributes of file objects with type bin_t.

SELinux allow rules, such as the previous example, actually grant access rights in SELinux. The real challenge is how to ensure that tens of thousands of accesses are correctly authorized and only grant necessary permissions to achieve the greatest possible security.

7.1 Setuid Programs in Standard Linux Security

The savvy user joe wants to change an existing password securely. The way Linux solves this problem is by giving passwd a setuid value, which makes it executable with root privileges. If you list the password file on a normal Linux system, you will see:

# ls -l /usr/bin/passwd
-rwsr-xr-x. 1 root root 41292 Sep 7 2012 /usr/bin/passwd

Note two things here. The first is that the x position in the owner permissions is set to s. This is the so-called setuid bit, which means that any process that executes this file will have its effective UID (user ID) changed to that of the file owner. Here, root is the file owner, so when the password program is executed it will actually run as the root user ID. The execution process is shown in the following figure:

From the above analysis, we can see that passwd runs with root privileges. It 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 accept access from passwd. This is not possible in standard Linux, but TE (type enforcement) can achieve this function.

8. Role-Based Access Control

SELinux also provides a role-based access control (RBAC). The RBAC feature of SELinux is based on type enforcement. Access control in SELinux is mainly implemented through types. Roles restrict the types that a process can transform to based on the role identifier in the process security context. In this way, a policy writer can create a role that allows it to transform into a set of domain types (assuming that the type enforcement rules allow the transformation), thereby defining the restrictions of the role.

9. Multi-Level Security in SELinux

Type Enforcement is undoubtedly the most important mandatory access control (MAC) mechanism introduced by SELinux. However, in some cases, mainly a subset of confidentiality control applications, the traditional multi-level security (MLS) MAC is more valuable when used in conjunction with type enforcement. In these cases, SELinux always includes some form of MLS functionality. The MLS feature is optional. Of the two MAC mechanisms in SELinux, it is not usually the most important one. For most secure applications, including many non-confidential data applications, type enforcement is the most suitable security enhancement mechanism. Nevertheless, MLS still enhances security for some applications.

In most SELinux policies, sensitivities (s0, s1, ...) and categories (c0, c1, ...) use wildcard names, leaving it to userspace programs and libraries to specify meaningful user names. (For example, s0 might be associated with UNCLASSIFIED and s1 might be associated with SECRET)
To support MLS, the security context is extended to include security levels, such as:

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

The following example shows an example:

root@luohj-virtual-machine:~# ps -aZ 
LABEL PID TTY TIME CMD 
unconfined_u:system_r:insmod_t:s0-s0:c0.c255 4940 pts/0 00:00:00 passwd

Note that an MLS security context must have at least one security level (which consists of a single sensitivity and zero or more categories), but can include two security levels, which are called Low (or process trend) and High (or process gap). If the High security level is missing, it is considered to be the same as the Low security level (the most common case). In practice, the Low and High security levels are usually the same for objects and processes. The level range commonly used for processes is considered to be a trusted subject (i.e., process trust downgrade information) or a multi-layer object, such as a directory, which includes objects of different security levels. To keep the description simple, it is assumed that all processes and objects have only one security level.

10. Strategy 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 relevant policies. xx is the version number of the policy compiler (checkpolicy).

11. Summary

SELinux access control is based on the security context associated with all system resources (including processes). The security context consists of three components: user, role, and type identifier. Type identifiers are the primary basis for access control.

In SELinux, the main feature of access control is type enforcement, which is access authorization between the subject (i.e., process) and the object by specifying allow rules (the subject's type [also called domain type] is the source, and the object's type is the target). Access is granted to specific object categories, and fine-grained permissions are set for each object category.

A key advantage of type enforcement is that it controls which programs may run in a given domain type. Therefore, it allows access control for individual programs (which is much more secure than user-level security controls). Enabling a program to enter another domain (i.e. run as a given process type) is called a domain transition, which is tightly controlled through SELinux's allow rules. SELinux also allows domain transitions to occur automatically through the type_transition file.

SELinux does not directly use role identifiers in the access control security context. Instead, all access is type-based, and roles are used to associate allowed domain types. This allows type-enforced allowed functions to be grouped together and users to be authenticated as a role.

SELinux provides an optional MLS access control mechanism, which provides more access restrictions. The MLS feature is built on the TE mechanism. MLS extends the content of the security context to include a current (or low) security level and an optional high security level.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.