Attention

You are viewing an older version of the documentation. The latest version is v3.3.

Security Enhanced Linux (SELinux)

Security-Enhanced Linux is a mandatory access control (MAC) security mechanism implemented in Linux kernel. These enhancements mean that content varies as to how to approach SELinux over time to solve problems.

Basic overview for Linux security

Each action is monitored by security mechanisms. One of those mechanisms can be the references monitor. The kernel of references monitor is access control.

../_images/ac.png

Obviously, a subject sends an access request into references monitor, and it will make a decision. If the request is certified, references monitor will respond and approve access to object. Therefore, subject can use object.

Definitions and Acronyms on SELinux

  • Subject: Entity requesting access which can be a human user or a process.

  • Object: The resource to which the subject is requesting access.

  • MAC: Mandatory access control.

  • DAC: Discretionary access control.

  • ACLs: Access control lists. A control list associated with each object listing the subjects or groups of subjects that are allowed to make access to the object.

  • AVC: SELinux log message. In general, log will be stored in /var/log/audit/audit.log.

SELinux Concept

Before SELinux access, only DAC methods such as file permissions or ACLs are used to control the file access of users. There are two privilege levels, root and user. Many processes that are launched by root later and deny access for a restricted user. SELinux follows the model of least-privilege more closely. By default under a strict enforcing setting, everything is denied and then a series of exception-policies are written that give each element of the system (service, program or user) only the access required to function. If a service, program or user subsequently tries to access or modify a file or resource not necessary for it to function, then access is denied and the action is logged.

For DAC system, Linux file security works with three entities ,i.e. user, group, other. Besides, each Linux file has certain permissions related to user, group, and other. We can do permission modification for file through certain commands

$ chmod [user][group][other] NewFile
$ chown [user]:[group] NewFile
../_images/dacmode.png

If MAC is required, the DAC method should be replaced with rule list as below.

  • Root compromises confined by policy.

  • Security policy set by administrator and enforced by the system.

SELinux Attribute

  • Object

Files
Sockets
Networks

  • Subject

Processes
Users
Daemon

  • Domain

  • Security Contexts

users (SELinux user account, default user is system_u)
role (Default role is system_r)
type (Default type is system_t)
level (option)
../_images/SecurityContexts.png

SELinux Modes

Disabled : SELinux is turned off.
Permissive : SELinux is enabled but will not enforce the security policy, only warn and log actions.
Enforceing : The default mode which will enable and enforce the SELinux security policy on the system, denying access and logging actions.
../_images/semodule.png

SELinux Policy

Multi-Level Security Policy (MLS) :
    Multi Level Security protection.
Minimum :
    Modification of targeted policy. Only selected processes are protected.
Targeted:
    - Type Enforcement (TE) : Type Enforcement is the primary mechanism of access control used in the targeted policy
    - Role-Based Access Control (RBAC) : Based around SELinux users, but not used in the default configuration of the targeted policy

With choosing the SELinux policy method, SELinux policy inspection tool can help to view the policy.

../_images/spolicy.png

Commands of SELinux

sestatus : information about current state
getenforce : get the enforcement mode
setenforce : change the enforcement mode
chcon : change the scontext of object
runcn : run in a different scontext
audit2allow : generates policy allow rules from logs of denied operations
getsebool : get statements in policy
setsebool : set statements in ploicy
semanage : semanage is used to configure certain elements of SELinux policy with-out requiring modification to or recompilation from policy source
seinfo : SELinux policy information tool
sepolicy : SELinux Policy Inspection Tool
semodule : Manage SELinux policy modules
ausearch : Search audit event

Learn from an example: (Make rt-data agent work under SELinux monitoring)

Step 1: Boot with SELinux

  • Check SELinux policy status

$ sestatus -v

  • Check the SELinux is enabled and SELinux current mode.

../_images/sestatus.png

  • Check audit function enable

$ dmesg | grep audit
../_images/dmsgaudit.png

Step 2: Run rt-data-service under SELinux

 Enable the policy for Real Time Data Agent

.. code-block:: console

   $ cd /opt/rt-data-agent/sim

   # Set SELinux permissibe mode temporarily, so we can modify the SELinux context or policy.
   $ setenforce 0
   # change the "sim_rt_send" context type "bin_t"
   $ chcon -Rv –t bin_t sim_rt_send

   # Please download paho dependence first before execute
   $ pip3 install paho-mqtt
   # change the "paho*" context user to "system_u"
   $ chcon -Rv -u system_u paho*

Open new terminal

# Run rt-data-server
$ /opt/rt-data-agent/sim/sim_rt_send

# Run rt-data-agent
$ python3.8 /opt/rt-data-agent/agnet/agnet.py

  • Step 3, Output the policy module and insert the module

    Temporary method

    # If there have some
$ audit2allow  -a -M rt_agent
rt_agent.pp
rt_agent.te
# semodule -i rt_agent.pp

    Permanent method

    # We confirm that the policy is workable. Next step, we are going to fetch relatived file, and make a patch into ECI module. Thence, the latest ECI image is access the policy in general.
# There are some packages we need to add into ECI build environment.
# rt-datra-agent.fc
# rt-datra-agent.te
# rt-datra-agent.if

# first, git clone source code and create new folder
$ git clone
$ mkdir -r policy/modules/sim_rt_send
$ mkdir -r policy/modules/agent

# we can fetch *.fc *.te *.if file from sepolicy command
$ sepolicy generate --init /opt/rt-data-agent/sim/sim_rt_send
Created the following files:
/root/sim_rt_send.te # Type Enforcement file
/root/sim_rt_send.if # Interface file
/root/sim_rt_send.fc # File Contexts file
$ cp /root/sim_rt_send.te  policy/modules/sim_rt_send
$ cp /root/sim_rt_send.if  policy/modules/sim_rt_send
$ cp /root/sim_rt_send.fc  policy/modules/sim_rt_send

$ sepolicy generate --init /opt/rt-data-agent/agent
Created the following files:
/root/agent.te # Type Enforcement file
/root/agent.if # Interface file
/root/agent.fc # File Contexts file
$ cp /root/agent.te  policy/modules/agent
$ cp /root/agent.if  policy/modules/agent
$ cp /root/agent.fc  policy/modules/agent

How to debug

  1. audit2allow Use audit2allow -a -w check the SELinux confined problems

  2. dmesg Use dmesg check the process log

  3. semanage semanage user -l semanage port -l semanage login -l semanage fcontext -l semanage boolean -l semanage permissive -l

Let’s have an example. The SELinux monitors access form subject to object, and records into the audit log. We can observe some errors in the audit log, which correspond to unconditioned rule.

$ vi /var/log/audit/audit.log
$ ausearch -m avc -c vi
../_images/ausearch.png

In the above figure, We know that a subject process vi with context root:staff_r:staff_t request access to object /var/log/audit/.audit.log.swp with context root:object_r:auditd_log_t. However, access control decision function disapprove the access, and record the audit log.

This audit may be caused by many reasons. For example, this request is not allowed by Profile (Rule) or, Subject and Object are not in AVC.