3 ms·

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 concern

by jude- 12y ago

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?

motoboi 12y ago
Does this apply to multiple containers instead of only two?
justincormack 12y ago
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.
- e12e 12y ago
  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.
kentonv 12y ago
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.

by jude- 12y ago

motoboi 12y ago

Does this apply to multiple containers instead of only two?

justincormack 12y ago

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.

e12e 12y ago
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.

kentonv 12y ago

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.