It starts with Linux: How Red Hat is helping to counter Linux container security flaws

The disclosure of a security flaw (CVE-2019-5736) in runc and docker illustrates a bad scenario for many IT administrators, managers, and CxOs. Containers represent a move back toward shared systems where applications from many different users all run on the same Linux host. Exploiting this vulnerability means that malicious code could potentially break containment, impacting not just a single container, but the entire container host, ultimately compromising the hundreds-to-thousands of other containers running on it. A cascading set of exploits affecting a wide range of interconnected production systems qualifies as a difficult scenario for any IT organization and that’s exactly what this vulnerability represents.

For many Red Hat end users, it’s unlikely that this flaw gets that far. IT organizations using Red Hat Enterprise Linux to underpin their Linux container and cloud-native deployments are likely protected, thanks to SELinux. This vulnerability is mitigated by the use of SELinux in targeted enforcing mode, which prevents this vulnerability from being exploited. The default for SELinux on Red Hat Enterprise Linux 7 is targeted enforcing mode and it is rarely disabled in a containerized environment.

This isn’t the first major flaw in a container runtime to come to light and, as container deployments and interest in associated technologies increase, it’s unlikely to be the last. Just as Spectre/Meltdown last year represented a shift in security research to processor architectures from software architectures, we should expect that low-level container runtimes like runc and container engines like docker will now experience additional scrutiny from researchers and potentially malicious actors as well.

To me, the underlying message here is: Containers are Linux.

Not exactly a newsworthy statement, I know, but it’s something that can be easily forgotten in modern IT, especially with the relative ubiquity of cloud-based container services and “throwaway” operating systems serving as container hosts. No matter the other bells, whistles and shiny objects that surround your container infrastructure, if your host layer isn’t properly updated and secured, your operations are likely at risk.

As far as container runtimes go, runc is used by just about every container engine out there - it’s a fundamental component of even the most basic Linux container implementations as a low-level runtime. As you might suspect by the name, this is a function that actually “runs” a given container and there is tight coupling between the features offered in runc and the Linux kernel. The OCI Runtime Specification is based on runc, and the runtime is used across a wide range of container infrastructure and Kubernetes offerings, including Red Hat OpenShift Container Platform.

But Linux still serves as the foundation, and that foundation, as today’s vulnerability illustrates, still really matters. Red Hat Enterprise Linux is the bedrock for Red Hat’s entire portfolio of solutions, providing a more secure building block for traditional and cloud-native infrastructure deployments. The world’s leading enterprise Linux platform is configured with secure defaults, such as SELinux enabled and in enforcing mode, at installation.

This commitment to security at the most basic level of operations means that users of most Red Hat technologies are not affected by this vulnerability as long as SELinux is in enforcing mode. As noted earlier, this is a default setting on Red Hat Enterprise Linux as well as Red Hat OpenShift, meaning that many customers can be protected against specific vulnerabilities, like today’s, without doing anything on their end.

End users should still patch the affected components. As Red Hat subscribers, this should be a relatively painless process thanks to Red Hat’s expertise in delivering enterprise-grade open source solutions. We don’t just spit out patches direct from the community - we analyze, test, harden and validate the code before it makes to users of our products, helping to limit the potential issues that can arise from patching production systems.

As infrastructure becomes more dense and containerized processes and applications impact more than just isolated systems, layered security measures become very important. It’s not just about having a firewall or access control or a vulnerability content scanner - modern IT deployments require stepped security measures addressing all levels of a software stack.

And again, even with containers, it all starts with Linux.

To read more about the runc vulnerability, check out the Red Hat article about the vulnerability as well as remediation steps that users can take to fully patch the flaw.

Scott McCarty is principal product manager, Containers, at Red Hat.