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

1. Brief introduction

The main value that SELinux brings to Linux is that it provides 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 mode tools

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

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

SELinux is transparent to system users (system users), and only the system administrator needs to consider how to make strict policies in his server. The strategy can be strict or lenient as needed.

The subject can access the object only if both Standard Linux access Control and SELinux access Control are satisfied.

1.1 key differences between DAC and MAC (root users)

Security fully enhanced Linux (SELinux) is started by NSA (National Security Agency) and added to the Linux system as a set of core components and user tools that allow applications to run on the minimum privileges they need. The unmodified Linux system uses discretionary access control, and users can request higher permissions on their own, so that malware can access almost any file it wants, but if you grant it root permissions, it can do anything.

There is no concept of root in SELinux, security policy is defined by administrators, and no software can replace it. This means that the damage that potential malware can cause can be kept to a minimum. In general, only enterprise users who pay great attention to data security will use SELinux.

The operating system has two types of access controls: discretionary access control (DAC) and mandatory access control (MAC). Standard Linux security is a DAC,SELinux that adds a flexible and configurable MAC to Linux.

A common weakness of all DAC mechanisms is that they cannot 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, and if the program is authorized to access, then malicious programs will have the same access. The most fundamental weakness of DAC is that the subject 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 (Type Enforcement) and a non-mandatory multi-layer security form (Multi-Level Security).

In Android4.2, SELinux is optional, and Google does not directly revoke root rights or other features. This is an option for enterprise users or users who attach great importance to private data, and the average consumer can turn it off.

2. The operation mechanism of SELinux

The SELinux decision process is shown in the following figure:

When an subject (e.g. an application) attempts to access an object (e.g. a file), the policy enforcement server in Kernel checks AVC (Access Vector Cache), and in AVC, the permissions of subject and object are cached (cached). If a decision cannot be made based on the data in AVC, request the security server, which looks for the security environment of "application + file" in a matrix. Access is then allowed or denied based on the results of the query, and the details of the deny message are in / var/log/messages.

3. SELinux pseudo file system

A command commonly used by the / selinux/ pseudo file system kernel subsystem, which is similar to the / proc/ pseudo file system. System administrators and users do not need to operate this part. An example of / 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-Rkhokashi-1 root root 0 Sep 22 13:14 mls-Ruki Ruki-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, the value of cat enforce may be as follows:

1: enforcing mode

0: permissive mode

4. SELinux configuration file

The SELinux configuration file (configuration) or policy file (policy) is located in the / etc/ directory.

4.1 / etc/sysconfig/selinux profile

/ etc/sysconfig/selinux is a symbolic link, and 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).

The following configuration options are included in / etc/sysconfig/selinux:

1) turn SELinux on or off

2) set which policy the system executes (policy)

3) set how the system enforces policies (policy)

4.2 profile options

4.2.1 SELINUX

SELINUX=enforcing | permissive | disabled-defines the advanced status 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 is executed by SELinux

Targeted-only the destination network daemons is protected. Whether or not each daemon enforces policies can be configured through system-config-selinux. Protect common network services, which is the default value of SELinux.

You can set the Boolean value for each daemon using the following tools:

1) getsebool-a: lists all Boolean values of SELinux

2) setsebool: set the SELinux Boolean value, for example: setsebool-P dhcpd_disable_trans=0,-P indicates that it is still valid even after using reboot.

Strict-performs full protection of SELinux. A security environment is defined for all subjects and objects, and each Action is processed by the policy enforcement server. Provide policy in accordance with Role-based-Access Control (RBAC), with complete protection functions to protect network services, general instructions and applications.

4.2.3 SETLOCALDEFS

SETLOCALDEFS=0 | 1-controls how the local definition (users and booleans) is set.

1: these definitions are controlled by load_policy, and load_policy comes from file / etc/selinux/0: controlled by semanage

4.3 / etc/selinux/ directory

/ etc/selinux/ is the directory where all policy files and major configuration files are stored. Examples are 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 tool

1) / usr/sbin/setenforce-modify the SELinux operation mode, as shown below:

Setenforce 1-SELinux runs setenforce 0-SELinux in enforcing mode and permissive mode

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

2) / usr/sbin/sestatus-v-shows the detailed status of the system. Examples are as follows:

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-run a new shell in a new context or role

4) / sbin/restorecon-sets the security environment for one or more files by tagging extended attributes 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 modifies the security context of files and directories

Chcon-u [user]

Chcon-r [role]

Chcon-t [type]

Chcon-R recursion

6. Type-enforced security context (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. "domain" and "domain type" have the same meaning. We do not have to distinguish or avoid using the technical register. We think that [domain], [domain type], [principal type] and [process type] are all synonymous, that is, they are all "TYPE" in the security context.

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

1) the system sets the security context for the login to run the program according to the pam_selinux.so module in the PAM subsystem

2) the Security Contex rules of the file are as follows:

Rpm package installation: the security context is generated according to the records in the rpm package; manually created files: the security context is set as specified in policy; cp: the security context is regenerated; mv: the security context remains the same.

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 properties of the associated object and subject. In SELinux, the access control attribute is called a security context. 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 often specified or displayed in the following format:

USER:ROLE:TYPE [LEVEL [: CATEGORY]]

User and role identifiers in the security context have no effect on type enforcement access control policies except for a little constraint on enforcement. For processes, user and role identifiers are more meaningful because they are a combination of control types and user identifiers, which are associated with Linux user accounts. However, for objects, user and role identifiers are rarely used. In order to standardize management, the role of the object is often object_r, and the user of the object is often the user identifier of the process that created the object, which has little effect on access control.

The difference between user ID in standard Linux security and user identifiers in security context is technically orthogonal identifiers, which are used for standard and security-enhanced access control mechanisms, respectively. Any correlation between the two is strictly enforced by the login process in accordance with the specification, rather than directly enforced through SELinux policies.

6.1.1 USER

1) user identity: similar to UID in Linux system, it provides identification and is used to record identity; part of the security context

2) three common user:

User_u: the default after ordinary users log in to the system; system_u: the preset of the system process during boot up; root: the preset after root login

3) users is not very important in targeted policy

4) it is more important in strict policy. All preset SELinux Users ends with "_ u" except root.

6.1.2 ROLE

1) role of files, directories, and devices: usually object_r

2) role of the program: usually system_r

3) the role:targeted policy of a user is the role of a user whose system_r; strict policy is sysadm_r, staff_r or user_r;, similar to the GID in the system. Different roles have different permissions. Users can have multiple role; but can only use one role at a 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 subject and object into different groups, define a type for each subject and object in the system, and provide the lowest permission environment for the process to run

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, which is the heart of SELinux Type Enforcement. The default value ends with _ t.

LEVEL and CATEGORY: define hierarchies and classifications, used only in mls policies

LEVEL: represents the security level. Currently, the defined security level is s0-s15, and the level is getting higher and higher. CATEGORY: stands for classification, and the currently defined category is c0-c1023.

6.2 compare the access control properties of SELinux and standard Linux

In the 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 login processes and setuid programs. For objects such as files, the inode of files includes a set of access mode bits, file users and group ID. The previous access control was based on the read / write / execute three control bits, one for the file owner, one for the group to which the file owner belongs, and one for others.

In SELinux, access control attributes are always in the form of a security context trio (user: role: type), and all objects and subjects have an associated security context. In particular, because the main access control feature of SELinux is type enforcement, the type identifier in the security context determines access.

Note: SELinux adds type enforcement (TE: Type Enforcement) to the standard Linux, which means that both standard Linux and SELinux access controls must be able to access an object first, for example: if we have SELinux write permission to 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 properties between standard Linux and SELinux:

Standard Linux

SELInux

Process security properties

Real and valid user and group ID

Security context

Object security attribute

Access mode, file user and group ID

Security context

Access Control Foundation

Access modes for process user / group ID and files

This access mode is based on the file's user / group ID

In process types and file types

Permissible licenses between

6.3 Summary

1) each file, directory, network port and so on in the system is assigned a security context, and policy gives the rules of action among the security contexts.

2) SELinux determines whether the access behavior is executable according to policy and security context rules

3) Subject: system processes, such as / usr/sbin/httpd

4) Object (object): accessed items, 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 there is no default superuser in SELinux. Unlike root in standard Linux, allow rules are used to grant access permissions by specifying subject types (i.e. domain) and object types. Allow rules are composed of four parts:

The source type (Source type (s)) is usually the domain type of the process attempted to access (Target type (s) the type of object accessed by the process (Object class (es)) specifies the type permission of the object allowed to be accessed (Permission (s)) symbolizes the type of access that the source type allows access to the type of access of the object type

Examples are as follows:

Allow user_t bin_t: file {read execute getattr}

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 name of the object category defined in the policy (in this case, a normal file). The permissions included in curly braces are a subset of the valid permissions of the file object category. This rule is interpreted as follows:

A process with a domain type user_t can read / execute or get the properties of a file object of type bin_t.

SELinux allow rules, such as the previous examples, actually grant access in SELinux. The real challenge is how to ensure that tens of thousands of access is authorized correctly, granting only the necessary permissions, and achieving as much security as possible.

Setuid Program in Standard Linux Security

Proficient user joe wants to safely modify the existing password problem. Linux solves this problem by assigning a setting value to passwd so that it has root permission when it executes. If you list the password file on an ordinary Linux system, you will see:

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

There are two things to note here. The first is that the x position of the owner permission is set to s, which is the so-called setuid bit, which means that any process executing the file, its valid UID (user ID) will be changed to the file owner. Here, root is the file owner, so when the password program is executed, it will actually run as the ID of the root user. The execution process is shown in the following figure:

As can be seen from the above analysis, passwd runs as root authority, and 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 be visited by passwd. This cannot be done in standard Linux, but TE (type enforcement) can do this.

8. Role-based access control

SELinux also provides a role-based access control (RBAC). The RBAC feature of SELinux is based on type enforcement, and access control in SELinux is mainly implemented through types. Roles restrict the types of processes that can be transformed based on role identifiers in the process security context, so that the policy writer can create a role that allows it to be transformed into a set of domain types (assuming type enforcement rules allow conversion) To define the limitations of the role.

9. Multi-level Security (Multi-Level Security) in SELinux

Type enforcement (Type Enforcement) is undoubtedly the most important mandatory access control (MAC) mechanism introduced by SELinux. However, in some cases, it is mainly a subset of security control applications, and the traditional multi-level security (MLS) MAC is more valuable to use with type enforcement. In these cases, SELinux always includes some format MLS function, and the MLS feature is optional, in the two MAC mechanisms of SELinux. It is not usually the most important one, and type enforcement is the most appropriate security enhancement mechanism for most secure applications, including many non-confidential data applications, but MLS enhances security for some applications.

In most SELinux strategies, sensitivity. And category (c0menthc1pr...) Use a wildcard name and leave it to user-space programs and libraries to specify a meaningful user name. (for example, S0 may be associated with UNCLASSIFIED, S1 may be associated with SECRET)

To support MLS, the security context has been extended to include security levels, such as:

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

Examples are as follows:

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 the MLS security context must have at least one security level (which consists of a single sensitivity and 0 or more categories), but can include two security levels, which are called low (or process trend) and high (or process gap), respectively, and if the high security level is lost, it is considered to be the same as the low security level (the most common case), in fact, for objects and processes Low and high security levels are usually the same, and the level scope commonly used for processes is considered to be trusted subjects (that is, process trust degradation information) or multi-tier objects, such as a directory, which includes objects with different security levels. To keep the description simple, assume that all processes and objects have only one level of security.

10. Policy Analysis tool apol

Apol (that is, analyze policy [Analysis 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, which consists of three components: user, role, and type identifier. Type identifiers are the main basis of access control.

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

One of the key advantages of type enforcement is that it controls which programs may run on a given domain type, so it allows access control to a single program (much more secure than user-level security control) and causes the program to enter another domain (that is, running with a given process type) is called domain transformation, which is tightly controlled by SELinux's allow rules SELinux also allows domain transitions to occur automatically through type_transition files.

SELinux does not directly use role identifiers in the context of access control security. Instead, all access is type-based, and roles are used to associate allowed domain types, so you can set types to force allowed functions to be grouped together to authenticate users as a role.

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

The above is the whole content of this article, I hope it will be helpful to your study, and I also hope that you will support it.

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.