LINUXMAKER, OpenSource, Tutorials

What is Security Enhanced Linux?

Usually, programs always use the account of the user who launches them. Important programs such as network services or database servers are started with root privileges, but then switch to an account with limited privileges. The rights system under Unix and thus also under Linux is relatively simple and thus offers only limited configuration options. This means that if an attacker can take control of a program, they can access many files that the program does not normally need. So runs a program under root rights own faulty code can be recorded and executed via detours.
Therefore, you will always avoid programs running permanently under root privileges. The most proven security measures are to forego demons with root privileges and install programs or scripts if possible not with the setuid bit.

Much more security is provided by the NSA as open-source code developed SELinux as a kernel extension. SELinux (Security Enhanced Linux) is a mandatory access control system built on Linux's Linux Security Modules (LSM) interface. In practice, the kernel queries SELinux before each system call to find out if the process is authorized to perform the operation. To do this, SELinux uses a set of rules - collectively referred to as policy - to authorize or prohibit operations. These rules are difficult to create. Fortunately, there are two standard policies (targeted and strict) that make most of the configuration work unnecessary.

MAC rules thus provide a much tighter security control than the Unix access system can provide. Thus, a program can generally prohibit access to certain directories or network functions independently of Unix accounts or access rights. Even if the program gets out of control, caused by a bug or security flaws, the rules are still exploiting because they are being monitored at the kernel level.

However, SELinux remains ineffective without the appropriate rules. So whether a system becomes safer with the use of SELinux depends crucially on the quality of the rules and regulations.
Since files with Extended Attributes must be signed, only EA-compatible file systems come into question, which definitely eliminates NFS.

Internal SELinux concept

Two foundations form the basis for SELinux. On the one hand, a security context identifies all files and processes, on the other hand, there are the rules that the monitored processes have to comply with. Thus, the objects (e.g., files) and each subject (e.g., processes) are coupled to a security context. This security context can be combined with

# ls -Z /etc/hosts
system_u:object_r:net_conf_t:s0 /etc/hosts

determine, or alternatively with

# getfattr -n security.selinux -d /etc/hosts
# file: etc/hosts

The context in the processes is called a domain. This security context of a domain can be determined with

# ps axZ
LABEL                             PID TTY      STAT   TIME COMMAND
system_u:system_r:init_t:s0         1 ?        Ss     0:00 /sbin/init
system_u:system_r:kernel_t:s0       2 ?        S      0:00 [kthreadd]
system_u:system_r:kernel_t:s0       3 ?        S      0:00 [ksoftirqd/0]

Normally, the process takes over the context of the account with which it is started. However, a SELinux rule can also change the context right after the start.

Syntax of the security context

The security context is made up of three or four parts separated by colons:

The type of file or process is the most important part in the third place. Because most SELinux rules evaluate this information. A detailed description of the safety concept components can be found here

A typical SELinux rule builds on the following syntax

allow type1_t type2_t:class { operations };

For example, the following rule allows the processors belonging to the context httpd_t to create new files in directories with the context type httpd_log_t:

allow httd_t httpd_log_t:dir create;

Handling newly created files

Immediately after installation, SELinux rules are appropriate for many directories, assigning appropriate contexts to the newly created files. As soon as files are moved, however, this automatism fails. In this case, restorecon will restore the context properly

restorecon -R -v /var/www/html/*

for example, corrects the context of all files stored in Apache's DocumentRoot directory. If, on the other hand, the HTML files are located in /srv/www, then the correct context must be set with chcon:

chcon -R system_u:object_r:httpd_sys_content_t:s0 /srv/www

Which context can be used is provided by the man pages, which document the SELinux rules for different programs. man apache_selinux provides the rules for the contexts of the Apache server.