In a reinforcement of his company’s marketing message that containerization as an architecture is more secure by design, Docker Inc. CEO Ben Golub [pictured right above, with HPE Executive VP Antonio Neri] told attendees at HPE’s Discover London 2016 event last Tuesday morning that the Docker platform addresses and ameliorates its users’ security concerns just by its very architecture.
“What we’ve heard from the most security-conscious organizations on the planet who are using Docker, is that they’re using Docker not in spite of security concerns, but in order to address the security concerns,” Golub told attendees.
The CEO then cited a July 2016 blog post by Gartner analyst Joerg Fritsch, advising the analyst group’s clients that containerized applications are typically more secure than applications running on bare metal, or on VM-based infrastructure.
“Although containers will not prevent applications from being compromised,” Fritsch wrote, “they greatly limit the damage of a successful compromise because applications and users are isolated on a per-container basis so that they cannot compromise other containers or the host OS — as long as a kernel privilege escalation vulnerability does not exist on the host OS.”
That last clause has been the key concern ever since the Docker security issue was first raised over two years ago. To this day, no successful, malicious exploits of this theoretical security hole are known to exist in the wild. But software engineers continue to this day to raise warnings that the host operating system kernel for a container may be compromised, leading to that container becoming completely exposed.
Last October, security developer Gabriel Lawrence posted to YouTube a video purporting to demonstrate how, in a secure test environment running on an Amazon AWS instance, a Linux kernel bug can be exploited to modify a container’s contents in such a way that it opens a shell into that container with root-level privileges.
The Linux function being exploited here is the copy-on-write (COW) feature, part of the code for which is evidently shared as part of a library across multiple Linux processes. Though we’ll refrain from explaining this exploit just enough to give anyone out there some bad ideas, suffice it to say that Lawrence’s demo appears to show arbitrary malicious code being copied into that same library, thus serving as an agent for delivering the exploit.
The MITRE CVE dictionary has cataloged this bug as CVE-2016-5195, and folks have taken to calling it “Dirty COW.” To be both fair and clear, this is a Linux bug and not a Docker bug.
But in a way, that’s the problem: The dependency of the Docker container upon the Linux kernel to serve as its sole host theoretically (and, as Lawrence may point out, actively) could expose the hosted container to whatever vulnerability the kernel itself faces. And as we’re coming to realize more clearly by the day, there may be numerous, unexploited bugs in Linux that have lain dormant since long before Docker was a twinkle in the whale’s eye.
In an interview last August with Docker security director Nathan McCauley for The New Stack Analysts podcast, he remarked that questions about the security of any new technology are likely to arise. But over the past two years, he said, his company and its contributors have introduced “foundational” security measures into the Docker platform. One of those measures is cryptographic node identity, which he described as a PKI registry that gives verifiable identity to individual server nodes in a Docker Swarm environment. Swarm is Docker’s orchestration engine, now embedded in the core Docker engine.
“We have implemented a PKI that is actually so easy to use,” said McCauley, “that in the initial demos we did, even here within Docker [Inc.], we didn’t say anything about it. We just turned it on, it was on by default, and all the commands look exactly the same. The reason why. . . is because they’re all built in by default. Every Docker Engine that is part of a Swarm gets a TLS identity, that enables us to build a bunch of stuff on top of that.”
In his comments to HPE Discover London, Docker Inc.’s Golub stated that it is the automation element of the Docker platform — which he didn’t name, though he meant Swarm — that completes its security model. By extension, he suggested that so long as data centers can trust the veracity of its container images, as well as the nodes that are hosting them in the server cluster, then the likelihood of being exploited by a dirty COW, or pig, or goat, or whatever may come down the Linux vulnerability pike, will be too negligible to mention.
“If you think about it, what it means: If everything you’re deploying is built from source, put into a container, digitally signed, can be scanned for known vulnerabilities, can be automated and tested, and [you can] have that happen in seconds,” said Golub, “[then] what you’re deploying into your infrastructure has a very low likelihood of being bad. And if there’s a problem — and of course, there’s always [problems] — you can track it and you can remediate it like [*snap*] that. You can push updates without having to take down servers, without having to do things like that. So you’re actually much more secure, much more resilient.”
Docker is a sponsor of The New Stack.