5 security technologies to know in Red Hat Enterprise Linux

Security is challenging, but it's essential, whether you're approaching security from a hygiene standpoint or because of regulatory compliance. Red Hat Enterprise Linux (RHEL) includes a host of security features. This article takes you on a short journey through some of the security features in RHEL.

Security Enhanced Linux

Security Enhanced Linux (SELinux) gets a bad rap. This mandatory access control layer in RHEL used to be difficult to configure and seemed to get in the way of everything. Those days have passed. SELinux is an integral part of RHEL, and the tooling around it has improved since the old days.

If you're running containers or virtual machines (VMs) on top of RHEL, you'll definitely want to have SELinux in enforcing mode. If you're running without SELinux, you should consider that SELinux has helped stop several vulnerabilities in their tracks. For example, SELinux thwarted CVE-2019-5736. Read more about it here.

If you're running a container or VM on RHEL, you probably already have SELinux enforcing, and you haven't even noticed. Containers and VMs require SELinux to provide the isolation they need.

[ Getting started with containers? Check out Deploying containerized applications: A technical overview. ]

SELinux has been enabled by default since RHEL 7 and provides access controls that separate processes, files, network devices, and users from each other. For containerized applications on RHEL, administrators can now use the udica utility to build SELinux policies for their applications. SELinux on RHEL 9 also includes performance improvements. From general code clean-up to deep optimizations in internal hash tables, you'll find SELinux's performance has improved.

System-wide crypto policies

Did you remember to disable TLSv1? How about SHA-1? You can make crypto policy changes system-wide with ease with a system-wide crypto policy tool. On most distributions, disabling a crypto algorithm requires changes in several places, both system and service levels. With the system-wide crypto policy tool, you can set a standard and apply it across the entire system.

A system-wide crypto policy tool will help you control what ciphers are used by OpenSSL, NSS, libgnutls, libgcrypt, and more, all with one command. The system-wide crypto policy is also used when implementing Federal Information Processing Standards (FIPS) crypto policies. And RHEL is one of the few Linux distributions that contains a tool like this.

You can learn more about system-wide crypto policies by getting your hands dirty in these online labs: Using system-wide cryptographic policy and Customizing the cryptographic policy.

Application allow-listing with fapolicyd

How about application allow-listing? Do you have a well-defined set of executables that should be allowed to run on your RHEL server? fapolicyd can help you lock in what's allowed to run and prevent anything that isn't. This configuration is perfect for systems that must exist in a hostile environment or under strict security requirements. fapolicyd uses digital signatures to determine if an application is unchanged and therefore allowed to run on the system. This is huge for preventing unknown code execution. One of the primary paths to compromise is pulling in a remote payload and executing it from a service account's home directory.

fapolicyd can help you prevent that exact scenario. Learn more about it in the Security hardening guide for Red Hat Enterprise Linux 9.

[ Want to test your sysadmin skills? Take a skills assessment today. ]

Network Bound Disk Encryption

Encryption at rest is a tricky problem. If you encrypt your disk, then to boot your system, you'll need to store the encryption key somewhere the system can reach. Many available solutions require the key and the encrypted volume to be stored on the same system. That's not ideal. You can move that encryption key off the system with Network Bound Disk Encryption (NBDE).

NBDE utilizes a system on your network external to your encrypted data. When a system boots or needs to unlock an encrypted volume, it checks in with the key server and unlocks the volume only if the key exchange is successful. If a disk is physically removed from your datacenter, it can no longer be unlocked without a password.

NBDE works great for mobile workstations. Imagine if your laptop could unlock automatically when you're within your corporate network, but it would require a password if it were lost or stolen.

Use the following links to learn more about Network Bound Disk Encryption:

• Red Hat Enterprise Linux Presents Episode 36
• Using RHEL System Roles to automate and manage Network Bound Disk Encryption

Built-in security compliance remediation

Security compliance can be tedious, but OpenSCAP has your back. Either at install time or on an existing deployment, OpenSCAP can be used to scan and remediate your systems to get them closer to compliant. Red Hat Satellite and Red Hat Insights also use OpenSCAP to detect and remediate compliance issues. You can even have OpenSCAP generate easy-to-read reports that inform security compliance audits or general good security hygiene. OpenSCAP includes definitions for PCI-DSS, STIG, CIS, and more.

Wrap up

I hope you've learned something about RHEL's security features. RHEL is backed by Red Hat's independent security validation through common criteria certification and FIPS. See the US Government Certifications Red Hat knowledgebase article for more info. If you'd like to try out security or other technologies in RHEL, please head to the online labs.

[ Keep your most commonly used commands handy with the Linux commands cheat sheet. ]