It's a real shame that there's no comparison with aufs as a baseline. They discount it for not being in mainline, but of course neither is overlayfs. The overlayfs author has been trying for upstream inclusion for years, maybe he'll see luck with his request for inclusion in 3.18: https://lkml.org/lkml/2014/9/29/350
Well, it's more likely to get in given that nobody is really pushing aufs any more. overlayfs is less ambitious and less featureful, which can of course be a big advantage when trying to get it in to the kernel.
OverlayFS’s speedup comes in part “by allowing the kernel to include only a single copy of a file read from multiple containers in it’s page cache.” I’m concerned that this could be a source of information leaks across containers.
Suppose container A reads a page from a file whose contents are shared with container B’s image. Container B can use the shared page cache to deduce when container A has read the file (and deduce which pages) by periodically reading the corresponding file in its root FS and recording how fast the kernel can serve it the page in question. Moreover, if the cache implementation is content addressable (i.e. the kernel determines a cache hit based on the hash of the page’s contents), B can guess the contents of A’s secret files’ pages by writing its guesses to a file and then reading them and recording how quickly the kernel serves them back.
Does OverlayFS (or some other system, like SELinux) mitigate these concerns?
You're worrying about a very tiny leak while ignoring the gaping hole next to it. :)
If a container is running actively malicious code, then you've probably already lost. The Linux kernel API is huge and local privilege escalation exploits are discovered on a regular basis (like every few weeks). Docker makes no real attempt to reduce that API -- it doesn't want to, because removing any feature would break some app. Docker really shouldn't be used as a sandbox; it should be used to run code that you trust but that you want to isolate for the purpose of easing deployment.
But, imagining for a moment if Docker were actually a sandbox...
> B can guess the contents of A’s secret files’ pages by writing its guesses to a file and then reading them and recording how quickly the kernel serves them back.
That kind of timing attack usually relies on systems where you can work on one byte at a time, cycling possibilities until you think you have it right, then go on to the next. In the hypothetical case you describe, though, you'd have to guess the entire 4k page at once. Even if the file just stores a single encryption key followed by zeros, you are still talking about an attack requiring 2^(key length in bits)*(time to force a cache flush and then wait for the other container to bring their file back into cache). You'd have an easier time bruteforcing the key from cyphertext.
The first part of your concern is true -- you'd probably be able to tell if anyone on the machine has (and is using) a particular file. Lots of systems have that kind of vulnerability, though, and there aren't a lot of interesting attacks that start from there.
It is not content based (well there might have been some dedup code available but you can disable it). The main thing is actually sharing shared libraries, and binaries. Which are I dont think a security risk.
Well... one might time how long it takes to load various patch-levels of... say the bash binary? And so deduce if another container is running known-vulnerable code, to later leverage that in a spearfishing attack.
As I understand it, the Flocker guys aren't really working on the CoW filesystem part of Docker, but solving the problems of data locality and persistence with regular (non-CoW) volumes mounted into a container.
That's correct - at ClusterHQ (makers of Flocker) we are focusing on using ZFS for volumes. ZFS itself is a copy-on-write filesystem, but we're using snapshots so that we can do send/recv between hosts, as opposed to using snapshots for the layers in a Docker image.
Separately to the work we're doing, the guys at Gandi (a European hosting company) are working on ZFS support for Docker images - see https://github.com/docker/docker/pull/7901
Combining these two efforts could result in a pure ZFS-on-root Docker distribution, which uses ZFS with Flocker for volumes, and ZFS for the Docker images themselves. That would be pretty cool, IMHO. ;)
