Threat Model Thursday: Files
Have you considered the idea that “Files are Fraught With Peril” lately? Maybe you should...There's a fascinating talk by Dan Luu, "Files are Fraught With Peril." The talk itself is fascinating, in a horrifying, nothing works, we're going to give up and raise goats now sort of way.
He starts from the startling decision of Dropbox to drop support for all Linux filesystems except Ext4. This surprising decision stems from the fact that a filesystem is a leaky abstraction, The interaction between performance and reliability means that fsync behaves strangely. His article is worth reading as a whole to see the fractal horror involved (and he doesn't even consider virtual machines, which I would expect would exacerbate the situation).
His article is worth reading in full, but as I read it, I considered: what do these failures of our mental models of filesystems mean for threat modeling? The filesystem model is leaky, and the leaks impact security (specifically, the integrity property, in that read returns precisely what was written). So what does that mean: is the operating system a tampering threat? Do we throw out threat modeling because a set of models is dangerously wrong?
I do not think the OS is a tampering threat, nor should we throw out threat modeling. We need to consider that the bugs exposed by the failure of storage models are generally that: bugs, whose violation of our expectations leads to some shocking results ("everyone agrees Postgres should crash?!?" Read Mr. Luu's article, please.) But still: bugs. Things that can be fixed or addressed. Threat modeling still helps us find exciting design issues, even while accepting that all models are wrong.