KDE Linux/Verity

As part of being modern and secure we may wish to consider a verity setup.

Simply put verity uses hash sums to verify data blocks are what they were expected to be (i.e. not tempered with while the system was offline).

There are two flavors available: dm-verity and fs-verity

dm-verity

dm-verity essentially works on a block level. You have a data partition and a hash partition and a root hash. The root hash gets encoded in the unified kernel image. Upon boot the hash partition is verified to match the root hash (i.e. the verity is valid). At runtime each read data block is verified against the hashes inside the hash partition.

You cannot only change the data partition as that would change the hashes, so the verification against the hash partition no longer works, leading to the kernel throwing IO errors. You also cannot only change the hash partition because then the root hash encoded in the UKI no longer checks out and of course the data verification also no longer applies. You also cannot only change the UKI because then the root hash would no longer check out. What you can do is change all three at the same time.

There is excellent support for this in systemd.

The problem with this is that we'd need a partition setup that, currently, would be hard to mutate. i.e. something like

[ESP] [ROOT] [USR1] [HASH1] [USR2] [HASH2]

The major advantage is that the data in the USR partitions don't need encryption because they are ultimately guarded by secureboot (UEFI secureboot -> UKI validation -> UKI roothash -> dm-verity), you cannot change it without changing the hash partitions, and you can't change the hash partition without changing the root hash, and you can't change the root hash because the UKI is secureboot validated which means you'd need to first break into secureboot.

fs-verity

fs-verity is the slightly less exciting brother. It works on a file level (no directories!) but otherwise mostly functions the same. When fs-verity is applied on a file, a tree of hashes is created and recorded in btrfs specific structures. This then produces a digest as root hash. It's basically a very fast way to checksum a file.

The main problem with this is that the entire filesystem must be encrypted for this to be totally trustworthy and as such all /usr access would be subject to performance penalty from decryption.

This would work with the current setup we have in KDE Linux:

[ESP] [Root (possibly encrypted; contains an erofs that contains the /usr]

Another problem is that there appears to be no tooling around this right now. In theory the simplest version would be a service in the initrd that ensures the digest of the erofs file is the expected digest. Since the UKI is secureboot protected you can't change the data at rest without breaking the expected digest.

When the btrfs is not encrypted it leads to the awkward problem that the btrfs itself could be tempered with to exploit a bug in the kernel though. Since dm-verity verifies on a block level it happens before the file system code even gets involved, preventing **any** mutation to the data blocks, even ones that would then target the file system implementation.

There are potentially also TOCTOU problems. Theoretically anyway. The file may be switched between digest and mount. Or with fs.verity.require_signatures=1 the fs-verity may be removed. How one would do that during initrd stage is anyone's guess though.

All that being said the question arises if fs-verity is useful for anything but integrity checks. Since it'd require encryption anyway.