How SELinux helps mitigate risk while facilitating compliance

This article was originally published on the Red Hat Customer Portal. The information may no longer be current.

Many of our customers are required to meet a variety of regulatory requirements. Red Hat Enterprise Linux includes security technologies that help meet these requirements. Improving Linux security also benefits our layered products, such as Red Hat OpenShift Container Platform and Red Hat OpenStackⓇ Platform.

In this blog post, we use PCI-DSS to highlight some of the benefits of SELinux. Though there are many other security standards that affect our customers, we selected PCI-DSS based on a review of customer support cases, feedback, and general inquiries we received. The items we selected from this standard are also accepted industry practices, such as:

• Limiting user access to data based on job roles.
• Limiting access to system components.
• Configuring software behavior, functions, and access.

What is SELinux?

SELinux is an advanced access control mechanism originally created by the United States National Security Agency. It was released under an open source license in 2000, and integrated into the Linux kernel in 2003. As part of the Linux kernel, it is built into the core of Red Hat Enterprise Linux. SELinux works by layering additional access controls on top of the traditional discretionary access controls that have been the basis of UNIX and Linux security for decades. SELinux access controls provide both increased granularity as well as a single security policy that is applied across the entire system and enforced by the RHEL kernel. SELinux enforces the security policy on applications bundled with Red Hat Enterprise Linux as well as any custom, third-party, and independent software vendor (ISV) applications. In addition to applications on the host system, SELinux access controls provide separation and controlled sharing between RHEL-hosted virtual machines and containers.

SELinux’s access controls are driven by a configurable security policy, which is loaded into the kernel at boot. The SELinux security policy functions as a whitelist for user and application behavior. The policy allows administrators and policy developers to isolate applications into specific SELinux domains that are tailored to the application’s permitted behaviors. Access to files, local interprocess communications (IPC) mechanisms, the network, and various other system resources can all be restricted on a per-domain basis. SELinux also allows the administrator to put individual SELinux domains, as well as the entire system, into permissive mode where SELinux-based access denials are logged, but the access is still permitted. This eases policy development and troubleshooting.

While SELinux is an important part of Red Hat Enterprise Linux security capabilities, there are many other security technologies and widely accepted practices that should also be employed. Data encryption, malware scanning, firewalls, and other network security mechanisms remain an important part of an overall security strategy. SELinux is a way to augment existing security solutions, and is not a replacement for current security measures that may be in place.

Mapping to compliance requirements

With the above understanding of how SELinux can help reduce risk and harden a Red Hat Enterprise Linux system, let’s see how it maps to a few PCI-DSS compliance requirements. When reviewing PCI-DSS 3.2 requirements, it is easy to see how RHEL with SELinux can help address requirements that fall under the section Implement Strong Access Control Measures Requirement. Let’s look at some lesser-known requirements in sections two and three instead.

PCI-DSS requirement 2.2:

“[d]evelop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.”

Given that, by default, it denies access to any resource rather than permits access, SELinux immediately meets industry-accepted system hardening standards, and may help mitigate certain classes of security vulnerabilities. It also helps meet the more granular requirements under 2.2 by ensuring a greater level of security restrictions and more fine-grained access control.

PCI-DSS requirement 3.6.7:

“Prevention of unauthorized substitution of cryptographic keys”

At a system-configuration level, SELinux can prevent unauthorized overwriting of files—even when a specific user or role would normally be authorized to write to the directory containing cryptographic keys.

SELinux can also help customers meet other well-known PCI-DSS 3.2 requirements by:
Limiting access to system components and cardholder data to only those individuals whose job requires such access. (meets 7.1.1 - 7.1.3)
Establishing an access control system(s) for systems components that restricts access based on a user’s need to know, and is set to ‘deny all’ unless specifically allowed. (meets 7.2.1 - 7.2.3)

Restricting malicious actor read, write, and pivoting

When SELinux is in enforcing mode, the default policy used in Red Hat Enterprise Linux is the targeted policy. In the default targeted policy, some applications run in a confined SELinux domain where SELinux policy restricts those applications to a particular set of behaviors. All other applications run in special unconfined domains; while they are still SELinux security domains, there is little to no restriction to their permitted behavior.

Almost every service that listens on a network is confined in RHEL, such as httpd and sshd. Also, most processes that run as the root user and perform tasks for users, such as the passwd utility, are confined. When a process is confined, it runs in its own domain. Depending on the SELinux policy configuration for a confined process, an attacker's access to resources, ability to pivot, read, and write, and the possible damage they can do may be limited.

We have listed below a few of the common processes and daemons that run confined by default in their own domain. If you have a question regarding a process that is not listed here, send your inquiry to Red Hat Customer Service.

• dhcpd is a dynamic host control protocol used in Red Hat Enterprise Linux to dynamically deliver and configure Layer 3 TCP/IP details for clients.
• smbd is a Samba server that provides file and print services between clients across various operating systems.
• httpd (Apache HTTP Server) provides a web server.
• Squid is a high-performance proxy caching server for web clients supporting FTP, Gopher, and HTTP data objects. It reduces bandwidth and improves response times by caching and reusing frequently requested web pages.
• mysqld is a multi-user, multi-threaded SQL database server that consists of the MariaDB server daemon (mysqld) and many client programs and libraries.
• PostgreSQL is an Object-Relational database management system (DBMS).
• Postfix is an open-source Mail Transport Agent (MTA), which supports protocols like LDAP, SMTP AUTH (SASL), and TLS.

For more information on how the Red Hat portfolio can help customers with PCI-DSS compliance, review Red Hat’s 2015 paper on PCI and DSS compliance and our 2016-2017 blog series.

Vulnerabilities

SELinux can also help mitigate many risks posed from privilege escalation attacks. SELinux policy rules define how processes access files and other processes. If a process is compromised, the attacker can only access resources granted to it through the associated SELinux domain. Exploiting an application does not change what SELinux allows the process to access. For example, if the Apache HTTP Server is compromised, an attacker cannot use that process to read files in user home directories by default, unless a specific SELinux policy rule was added or configured to allow such access.

Based on our review of data from the 2017 calendar year, we selected three vulnerabilities publicly released during that time which were mitigated by default Red Hat Enterprise Linux SELinux policies.

CVE-2016-9962 targeted containers, and it became public just 11 days into the new year. 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. With SELinux in enforcing mode, and enabling the default SELinux policy (deny_ptrace) which only affects the policy shipped by Fedora or Red Hat, customers can:
- remove all ptrace,
- confine an unconfined domain, and
- retain the flexibility to disable it permanently or temporarily for troubleshooting.

CVE-2017-6074 addressed a flaw in the Datagram Congestion Control Protocol (DCCP). If exploited by a local, unprivileged user, the user could alter the kernel memory and escalate their privileges on the system. With SELinux enabled and using the default policies alone, this flaw is mitigated.

CVE-2017-7494 addressed a vulnerable Samba client. A malicious authenticated Samba client, having write access to the Samba share, could use this flaw to execute arbitrary code as root. When SELinux is enabled by default, our default policy prevents loading of modules from outside of Samba's module directories and therefore mitigates the flaw.

Red Hat and security

At Red Hat we believe that security is a mindset, not a feature. That’s why we work closely with upstream developers and communities to encourage secure coding practices, information sharing, and collaboration. We firmly believe the principles of open source software contribute to transparency and more secure products, benefiting customers and communities alike.

SELinux is shipped enabled by default in Red Hat Enterprise Linux. In addition to providing added security and mitigating a threat actor’s ability to pivot, SELinux also helps customers meet a variety of compliance standards requirements. And although the terms compliant and secure are not directly interchangeable, we understand that both are very important to our customers. We work continuously to support our products and help our customers achieve both business objectives.

For more information on Red Hat Product Security, visit the Product Security Center on the Red Hat Customer Portal. If you have vulnerability information you would like to share with us, please send an email to secalert@redhat.com.