Protecting files with fs-verity

Posted Aug 31, 2018 1:38 UTC (Fri) by josh (subscriber, #17465)
Parent article: Protecting files with fs-verity

So, dm-verity makes a whole block device immutable and verifies that it matches a tree of hashes, often provided separately such as via a root hash on the kernel command line. (Chrome OS uses this.)

fs-verity includes the hashes inline in the filesystem. What integrity properties does this provide that standard immutable files don't? If you can modify the filesystem, you can modify the hash tree. If you *can't* modify the filesystem, then you couldn't change an immutable file either. And I don't see anything about chaining those file-level hashes up to a higher-level hash provided elsewhere.

So I think I'm missing the threat model that fs-verity protects against.

Protecting files with fs-verity

Posted Aug 31, 2018 2:16 UTC (Fri) by zyzzyva (guest, #107472) [Link]

The top-level file hash, or "file measurement", is *not* stored on disk. It's up to either userspace (via FS_IOC_MEASURE_VERITY) or an in-kernel policy (like the built-in signature support in v1 patch 07/10, or the planned IMA support) to do something with that top-level hash, such as verifying that it matches a known good value, matches a valid digital signature, or even just logging it. In the Android APK use case, the hash will be verified against a signature.

With just a regular immutable file there is no such file hash available. Of course, you can just hash the whole file, but that is slow on large files, and the contents could change when paged into memory again (which fs-verity detects, like dm-verity).

Protecting files with fs-verity

Posted Aug 31, 2018 4:00 UTC (Fri) by TheJH (subscriber, #101155) [Link]

You can have an FS_VERITY_EXT_PKCS7_SIGNATURE extension in the fs-verity descriptor at the end of the file.