If your company uses or develops its own cloud-based software, then you’ll probably have run across containers. They’re a great technology to spin up fast, nimble cloud computing services, but they’ve also had a key security flaw. Over the past couple of years, engineers have been working to fix it.
Containers are a little like virtual machines (VMs), in that they enable you to run programs that are isolated from each other. Unlike VMs, though, they share some of the underlying operating system's resources rather that recreating an entire OS in hardware.
The problem is that containers as crafted in systems like Docker originally needed an account with root privileges on the host OS. Root is like ‘god mode’ for a user, giving them complete control. As the container uses the underlying OS kernel, if a malicious container is able to break out of its isolation, it could wreak havoc on the host, and potentially affect other containers too.
Good security practice includes running all software with the lowest privileges possible on the basis that it could be compromised. If an attacker hijacks it, restricted privileges mean that they can’t do as much damage with it. So engineers worked on removing that need for root access in containers.
Rootless containers change the game, enabling users to create them without root access. They map user IDs in the container to different user IDs on the host system, and use several other tricks to eliminate the need for root access.
They’re now part of the open container runtime specification, which is a project from the Open Container Initiative, meaning that it has made its way into anchor projects like Kubernetes, which administrators use to manage containers at scale. There are also other projects, like Podman, which is an alternative to Docker (although Docker also now supports a rootless container mode).
Rootless containers are tricky to engineer because some key functions have traditionally required root access. This includes the creation of network bridges that enable the container to talk to the host (and therefore everything else, including the general internet). It also needs access to some sort of root file system, which rootless systems cut off. So engineers solved this using a networking tool called Slirp, and a file system tool called fuse-overlayfs.
The tooling can still have vulnerabilities, though. A recent blog post from engineers at Palo Alto’s Unit 42 security team revealed a flaw in Slirp. That was just a denial of service vulnerability that could cause someone to crash it and cut off the container, but the post highlights other vulnerabilities discovered this year that could result in privilege elevation and even container breakouts.
Rootless containers are a more secure approach to running container software in your infrastructure but they’re not foolproof. Not only can the tools that allow them to run be compromised, but so can the kernel of the host OS, and the underlying hardware. We have to assume that everything is breakable, and use multiple layers of defense to minimize the probability of compromise.
To that end, you could use containers in conjunction with other security measures, including SELinux, which is a hardened Linux distribution. As the pace of innovation accelerates in this exciting space, it’s important to consider all the protective measures available to us.