How can SELinux Enforcing mode protect against vulnerabilities and weaknesses?

Resolution

SELinux (Security-Enhanced Linux) should ideally be configured to enforce mode on a Linux system for several important reasons, as it provides enhanced security protections against various vulnerabilities and weaknesses. Here's why SELinux should typically be set to enforcing mode and the types of security issues it helps protect against:

• Mandatory Access Control (MAC): SELinux enforces a mandatory access control policy, which is more restrictive than the traditional discretionary access control (DAC) model. In DAC, access control decisions are typically based on file ownership and permissions, and users have significant control over their own files. In contrast, SELinux policies are enforced independently of file ownership, providing a higher level of security.

• Principle of Least Privilege: SELinux enforces the principle of least privilege, meaning that processes and users are granted only the minimum level of access necessary to perform their tasks. This limits the potential damage that can be caused by vulnerabilities or malicious code. Even if an attacker manages to exploit a vulnerability, SELinux can prevent them from accessing sensitive resources or performing unauthorized actions.

• Defense in Depth: Security experts often recommend a defense-in-depth approach, which involves using multiple layers of security mechanisms to protect a system. SELinux adds an additional layer of security that can help mitigate the impact of vulnerabilities. It acts as a safety net, reducing the likelihood of successful attacks and providing a last line of defense when other security measures fail.

• Zero-Day Vulnerabilities: SELinux can help mitigate the impact of zero-day vulnerabilities—security flaws that are unknown to the software vendor or have no available patches. Even in the absence of a fix, SELinux can restrict the actions that a compromised process can take, limiting the potential damage.

• Granular Access Control: SELinux policies define detailed rules that specify which processes can access specific files, directories, and system resources. This granularity allows administrators to tailor security policies to their specific needs and reduce the attack surface by limiting unnecessary access.

• Isolation: SELinux can isolate different parts of a system by confining processes into separate security domains or contexts. Even if one process is compromised, it will be isolated from other processes and resources, reducing the potential for lateral movement by an attacker.

  For example, when running SELinux, unless otherwise configured, an attacker cannot compromise a Samba server, and then use that Samba server as an attack vector to read and write to files used by other processes, such as MariaDB databases.

• Audit Trails: SELinux generates detailed audit logs that record all security-relevant events, including policy violations and access attempts. These logs can be invaluable for monitoring and incident response, helping administrators detect and investigate security incidents.

• Default-Deny Policy: SELinux policies typically start with a "default-deny" stance, meaning that nothing is allowed unless explicitly permitted. This encourages administrators to define and document security policies, reducing the attack surface.

Here are some Common Vulnerabilities and Exposures (CVEs) where SELinux can play a role in mitigating the risks:

• CVE-2016-9962

Vulnerability: The runc component used by docker exec feature of docker allowed additional container processes to be ptraced by the pid 1 of the container. This allows the main processes of the container, if running as root, to gain low-level access to these new processes during initialization. An attacker can, depending on the nature of the incoming process, leverage this to elevate access to the host. This ranges from accessing host content through the file descriptors of the incoming process to, potentially, a complete container escape by leveraging memory access or syscall interception.

SELinux Mitigation: On Red Hat systems with SELinux enabled, the dangers of even privileged containers are mitigated. SELinux prevents container processes from accessing host content even if those container processes manage to gain access to the actual file descriptors.     

• CVE-2022-0492

Vulnerability: A vulnerability was found in the Linux kernel’s cgroup_release_agent_write in the kernel/cgroup/cgroup-v1.c function. This flaw, under certain circumstances, allows the use of the cgroups v1 release_agent feature to escalate privileges and bypass the namespace isolation unexpectedly.

SELinux Mitigation: In the OpenShift Container Platform (OCP) the container escape and privilege escalation caused by the vulnerability are blocked by the SELinux policy enabled (by default) on the OCP cluster nodes. Red Hat Virtualization requires SELinux running in enforcing mode on all hypervisors and managers, which blocks this vulnerability. Refer to: https://access.redhat.com/solutions/499473

• CVE-2019-5736

Vulnerability: A flaw was found in the way runc handled system file descriptors when running containers. A malicious container could use this flaw to overwrite contents of the runc binary and consequently run arbitrary commands on the container host system.

SELinux Mitigation: This vulnerability is mitigated on Red Hat Enterprise Linux 7 if SELinux is in enforcing mode. SELinux in enforcing mode is a pre-requisite for OpenShift Container Platform 3.x.

• CVE-2021-3156

Vulnerability: A flaw was found in sudo. A heap-based buffer overflow was found in the way sudo parses command line arguments. This flaw is exploitable by any local user who can execute the sudo command (by default, any local user can execute sudo) without authentication. Successful exploitation of this flaw could lead to privilege escalation. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

SELinux Mitigation: SELinux can confine the sudo process to restrict its access to sensitive files and directories. This would limit the damage an attacker can do even if they exploit the vulnerability.

• CVE-2019-9213

Vulnerability: A flaw was found in mmap in the Linux kernel allowing the process to map a null page. This allows attackers to abuse this mechanism to turn null pointer dereferences into workable exploits.

SELinux Mitigation: Enabling selinux prevents the public exploit from working correctly.

• CVE-2019-13272

Vulnerability: A flaw was found in the way PTRACE_TRACEME functionality was handled in the Linux kernel. The kernel's implementation of ptrace can inadvertently grant elevated permissions to an attacker who can then abuse the relationship between the tracer and the process being traced. This flaw could allow a local, unprivileged user to increase their privileges on the system or cause a denial of service.

SELinux Mitigation: The deny_ptrace SELinux boolean and SELinux in enforcing mode protect systems from the PTRACE_TRACEME vulnerability. Such configuration prevents scenarios when an attacker can get root privileges.

In summary, By enforcing mandatory access controls and confinement policies, SELinux can help protect Red Hat-based Linux systems against various vulnerabilities and weaknesses. It provides an additional layer of defense, reducing the attack surface and limiting the impact of successful attacks. However, it's important to note that SELinux requires careful configuration and policy management to strike the right balance between security and functionality.

For more information on Why you should set SELinux to Enforcing rather than Permissive, see Why you should set SELinux to Enforcing rather than Permissive

For more details on How to change the SELinux mode from Permissive to Enforcing, see Changing to enforcing mode