Docker’s security woes
I’d love to use Docker and, particularly, Fig. The deployment of even this site would be much simpler if I could update individual containers rather than having a somewhat complex set of services running together on a single host.
As of now, however, I’m starting to lose trust in Docker’s security team.
In October, Docker, Inc. announced that version 1.3 of the docker tool would verify container images downloaded from the central docker image repository:
First up, in this release, the Docker Engine will now automatically verify the provenance and integrity of all Official Repos using digital signatures. Official Repos are Docker images curated and optimized by the Docker community to be the best building blocks for assembling distributed applications. A valid signature provides an added level of trust by indicating that the Official Repo image has not been tampered with.
Sounds great, even if it is a bit vague (“using digital signatures”? What strength? etc.). Well, two things:
- Why did it take until 1.3 to introduce this feature? I question Docker’s priorities.
- It doesn’t appear to work.
Following a trust, but verify approach, research in this post indicates that the code implementing the verification doesn’t appear to work correctly. The conclusion:
Docker’s report that a downloaded image is “verified” is based solely on the presence of a signed manifest, and Docker never verifies the image checksum from the manifest. An attacker could provide any image alongside a signed manifest.
The core problem is that even if you trust both the original provider and Docker’s stewardship of the image, you cannot guarantee the image isn’t modified by a malicious party before it arrives on your machine.
It’s worth reading the rest of the post to understand the scope of the exploits. In particular, they are mitigated if one can trust the images one uses. Red Hat discuss some ways to do this. This does mean that there appear to be safe ways to use the docker tool.
However, this still worries me. One of Docker’s core products is their repository of container images. This is the reason I questioned Docker’s priorities above: if one can’t verify the provanence of the image that ends up on your machine via that central repo (you can’t be sure it hasn’t been modified before arriving on your machine), this product isn’t workable for production systems. Particularly because docker’s recent serious security issues involved the processing of malicious images — see here and here — a level of trust in the images received from the repository docker provides is essential. I therefore find it problematic that image verification seemed low on Docker’s priority list.
In summary, if this issue is correct, Docker has trust issues to work out: this flaw should not have made it into a production release. As more features roll out, docker’s attack surface increases. I’d like to see work in progress to mitigate that. In particular, a reworking of the central deamon to run as few things as possible as root.
Updated: clarified my argument.