Threat Model Thursday: Files

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.

1 Comment on "Threat Model Thursday: Files"

  1. I was asked last week: How would you integrity protect a database?

    There are so many different levers ranging from weak (use a journaled filesystem and trust access) to seemingly strong (salted hash every key record into a shadow table). It depends on the threat-scape and the accepted risks. And as the article points out, underlying implementations.

    I once saw a bug where memcpy worked differently on 1 out of 7 Posix systems. In that system, the mem copy did not take into account potential overlap in the buffers. If the buffers overlap, you may need to start copying from the back of the “from” buffer to ensure the final buffer is right.

    As we know, these needles are still lying around and I never walk through a haystack these days without boots 😉

Comments are closed.