Skip to main content
Engineering LibreTexts

12-C.10: SELinux Configuration

  • Page ID
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    3.1 Given a scenario, apply or acquire the appropriate user and/or group permissions and ownership.
    4.3 Given a scenario, analyze and troubleshoot user issues.
    4.4 Given a scenario, analyze and troubleshoot application and hardware issues.

    What is Context-Based Authentication?

    In the simplest terms, context-based authentication adds flexibility to multi-factor authentication (MFA). It builds risk assessment capabilities into access decisions by analyzing users’ behavior and context, such as which device or network they’re logging in from. If used successfully, it helps better protect your resources and enhances employee login experiences—finding that crucial balance between security and usability that most organizations strive for.

    In the Linux realm there are two main context-based authentication schemes that are available to system administrators: 1) SELinux and 2) AppArmor. We will take a look at both of these concepts in this section.

    What is Mandatory Access Control?

    In computer security, mandatory access control (MAC) refers to a type of access control by which the operating system constrains the ability of a subject or initiator to access or generally perform some sort of operation on an object or target. In practice, a subject is usually a process or thread; objects are constructs such as files, directories, TCP/UDP ports, shared memory segments, IO devices, etc. Subjects and objects each have a set of security attributes. Whenever a subject attempts to access an object, an authorization rule enforced by the operating system kernel examines these security attributes and decides whether the access can take place. Any operation by any subject on any object is tested against the set of authorization rules (aka policy) to determine if the operation is allowed.

    With mandatory access control, this security policy is centrally controlled by a security policy administrator; users do not have the ability to override the policy and, for example, grant access to files that would otherwise be restricted. By contrast, discretionary access control (DAC), which also governs the ability of subjects to access objects, allows users the ability to make policy decisions and/or assign security attributes.

    What is SELinux?

    Security-Enhanced Linux (SELinux) is a Linux kernel security module that provides a mechanism for supporting access control security policies, including mandatory access controls (MAC).

    SELinux is a set of kernel modifications and user-space tools that have been added to various Linux distributions. Its architecture strives to separate enforcement of security decisions from the security policy, and streamlines the amount of software involved with security policy enforcement. The key concepts underlying SELinux can be traced to several earlier projects by the United States National Security Agency (NSA).

    Contexts Within SELinux

    SELinux Users

    A SELinux user is an identifier that administrators can use to limit which SELinux roles can be used. A Linux account is mapped to one (and only one) SELinux user, whereas a SELinux user can be linked to multiple roles. As roles define the privileges of a user, this is effectively used to limit the ability of users to run or execute particular applications.

    The following table gives a non-exhaustive list of SELinux users which can be found on most SELinux systems.

    SELinux User Description Used For
    unconfined_u SELinux user meant for unrestricted users. Unconfined users have hardly any restrictions in a SELinux context and are meant for systems where only Internet-facing services should run confined (i.e. the targeted SELinux policy store). All users on a targeted system
    root The SELinux user meant for the root account. The Linux root account
    sysadm_u SELinux user with direct system administrative role assigned. Linux accounts that only perform administrative tasks
    staff_u SELinux user for operators that need to run both non-administrative commands (through the staff_r role) and administrative commands (through the sysadm_r role). Linux accounts used for both end user usage as well as administrative tasks
    user_u SELinux user for non-privileged accounts. Unprivileged Linux accounts
    system_u Special SELinux user meant for system services. Not used directly

    SELinux Role

    Part of SELinux is the Role-Based Access Control (RBAC) security model. The role is an attribute of RBAC. SELinux users are authorized for roles, and roles are authorized for domains. The role serves as an intermediary between domains and SELinux users. The roles that can be entered determine which domains can be entered - ultimately, this controls which object types can be accessed. This helps reduce vulnerability to privilege escalation attacks.

    SELinux Type

    The type is an attribute of Type Enforcement. The type defines a domain for processes, and a type for files. SELinux policy rules define how types can access each other, whether it be a domain accessing a type, or a domain accessing another domain. Access is only allowed if a specific SELinux policy rule exists that allows it.

    Notice the output in the following example. There is information that we haven't seen before. This is the SELinux context information: unconfirmed_u - is the user; object_r - the role; and default_t - is the type.

    # ls -dZ /web
    drwxr-xr-x  root root unconfined_u:object_r:default_t:s0 /web
    # ls -lZ /web
    -rw-r--r--  root root unconfined_u:object_r:default_t:s0 file1
    -rw-r--r--  root root unconfined_u:object_r:default_t:s0 file2
    -rw-r--r--  root root unconfined_u:object_r:default_t:s0 file3

    SELinux Modes

    SELinux has three modes:

    • Enforcing: SELinux policy is enforced. SELinux denies access based on SELinux policy rules.


    • Permissive: SELinux policy is not enforced. SELinux does not deny access, but denials are logged for actions that would have been denied if running in enforcing mode.


    • Disabled: SELinux is disabled. Only DAC rules are used. MAC is not implemented.


    Use the /usr/sbin/setenforce command to change between enforcing and permissive mode. Changes made with /usr/sbin/setenforce do not persist across reboots. To change to enforcing mode, as the Linux root user, run the /usr/sbin/setenforce 1 command. To change to permissive mode, run the /usr/sbin/setenforce 0 command. Use the /usr/sbin/getenforce command to view the current SELinux mode.

    SELinux Policies

    SELinux follows the model of least-privilege; by default everything is denied and then a policy is written that gives each element of the system only the access required to function. This description best describes the strict policy. However, such a policy is difficult to write which would be suitable in the wide range of circumstances that a product such as Enterprise Linux is likely to be used in. The end result is that SELinux is likely to cause problems for system administrators and end users and rather than resolve these issues, system administrators may just disable SELinux, thereby defeating the built-in protections.

    Gentoo, and several other distributions, support four policy types within SELinux: strict, targeted, mcs and mls.

    The differentiation between strict and targeted is based upon the unconfined domain. When loaded, the processes on the system that are not specifically confined within a particular policy module will be part of the unconfined domains, whose purpose is to allow most activities by default (rather than deny by default). As a result, processes that run inside unconfined domains have no restrictions apart from those already enforced by standard Linux security. Although running without the unconfined domains is considered more secure, it will also be more challenging for the administrator to make sure the system still functions properly as there are no policy modules for each and every application "out there."

    Next to targeted and strict, administrators can opt for mcs to allow categorization of resources. This is useful on multi-tenant systems such as web servers or virtualization hosts, where multiple processes will be running, most of them in the same security domain, but in different categories. Note though that to take advantage of the additional category support, either the applications themselves (such as the web server or hypervisor tools) need to configure the SELinux categories (so they need to support SELinux) or the administrator will need to script around to start the individual instances with separate categories. Otherwise, mcs is just the same as targeted or strict.

    SELinux Commands

    Command Used for
    semanage SELinux Policy Management tool
    sestatus SELinux status tool
    setenforce Modifies the mode SELinux is running in
    getenforce Gets the current mode of SELinux
    getsebool Gets SELinux boolean value(s)
    setsebool Sets SELinux boolean value

    Detecting Violations in SELinux

    Once SELinux is enforced on a system the violation messages need to be captured. A violation occurs when an attempt is made to access an object, or an action goes against an existing policy. When a system is first put under SELinux, it is possible to get false violations due to policies that might need to be tweaked by it.

    Using the sealert command the alert messages should be sent to the audit log.

    pbmac@pbmac-server $ sealert -a /var/log/audit/audit.log

    For example, let’s assume you’ve got this line in your /var/log/audit/audit.log file:

    type=AVC msg=audit(1415714880.156:29): avc:  denied  { name_connect } for  pid=1349 \
      comm="nginx" dest=8080 scontext=unconfined_u:system_r:httpd_t:s0 \
      tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket

    Execute this command to get a diagnostic:

    # grep 1415714880.156:29 /var/log/audit/audit.log | audit2why
            Was caused by:
            One of the following booleans was set incorrectly.
            Allow httpd to act as a relay
            Allow access by executing:
            # setsebool -P httpd_can_network_relay 1
            Allow HTTPD scripts and modules to connect to the network using TCP.
            Allow access by executing:
            # setsebool -P httpd_can_network_connect 1

    Notice that at the end of the audit2why output there is a suggested command to resolve this problem. Make sure you understand what the command does before you simply execute it. You want to make sure that the command is NOT going to undo some necessary protection for the system.

    Adapted from:
    "5.5. SELinux Modes" by Multiple Contributors is licensed under CC BY-SA 3.0
    "SELinux/Tutorials/How is the policy provided and loaded" by Multiple Contributors is licensed under CC BY-SA 3.0
    "SELinux/Policy" by Multiple Contributors is licensed under CC BY-SA 3.0

    12-C.10: SELinux Configuration is shared under a CC BY-SA 4.0 license and was authored, remixed, and/or curated by LibreTexts.

    • Was this article helpful?