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 al

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.