What is with that call?

Bryan, if you're reading this, it's merely because I doubt that you actually check Linux bugtrackers.

Also, GNU tail provides tail -F, which does what you want tail -f to do. There is a reason for this. I don't remember what it is, but I think the manpage talks about it.

Ironically, given that you mention M. Cantrill, GNU tail does not really handle truncation properly, and gives up for almost the very case that M. Cantrill did: when the truncation doesn't decrease the size, or is very closely followed by a write that ends up not decreasing the size.

Of course, truncation is not the best way to organize writing log files in the first place. daemontools family style log management (in cyclog, multilog, et al.) starts a fresh file whenever there is a rotation, so these problems of truncation never arise.

And as I then went on to explain, this whole idea of truncating one log file over and over is a poor one, and not the best way to do logging in the first place. So the fact that both M. Cantrill and the GNU people gave up should perhaps be viewed as stopping when an inferior mechanism is pushed beyond its limits.

The ambiguities of language sometimes make two people with the same idea think their ideas are different.

What would have helped:

* Block ptrace() syscall using seccomp.

* Don't mount /proc, or mount it read-only.

As I understand it, those steps would close all attack vectors for this bug.

FWIW, the Sandstorm.io sandbox blocks ptrace() and doesn't mount /proc at all, so I think the bug has never been exploitable by Sansdtorm apps. (Disclosure: I am the tech lead of Sandstorm.)

I think Docker now defaults to mounting /proc read-only and blocking ptrace(), so it may mitigate this vulnerability as well, but I'm not 100% sure about that.

https://sandstorm.io/news/2016-10-25-cve-2016-5195-dirtycow-...

Of course, if you have evidence to the contrary, we'd all like to know about it!

(You are technically correct that the writes can come from another thread rather than another process, but the important part is that it has to go through one of those interfaces.)

> Please note that this mitigation disables ptrace functionality which debuggers and programs that inspect other processes (virus scanners) use and thus these programs won't be operational.

> The in the wild exploit we are aware of doesn't work on Red Hat Enterprise Linux 5 and 6 out of the box because on one side of the race it writes to /proc/self/mem, but /proc/self/mem is not writable on Red Hat Enterprise Linux 5 and 6.

Is everyone barking up the wrong tree here?

EDIT: All of the PoCs here use ptrace() or /proc/self/mem. Why would they do that if they didn't need to?

https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs

(They're actually completely different products.)

The state of the disk and mounting of the disk generally wouldn't matter because the page is already being forced from read to read/write, and that has no barring on the mounting of or data on the actual disk. It doesn't matter if this data is actually flushed to the disk as long as the kernel uses it from cache without noticing it has been changed (Which it probably doesn't check regardless of read-only status).

If you want a secure system by default, you should probably not use Linux. I would go with OSX or OpenBSD to start.

(And finally: mounting /usr read-only isn't actually a security feature, because if you can exec code you can run a privesc and remount /usr read-write; mounting as noexec could arguably be considered a security feature)

Not really surprising since it's overwhelmingly used in practice as a single-user system.