[systemd-devel] Authenticated Boot: dm-integrity modes

[Adrian Vovk]

Some more thoughts about the usefulness of dm-integrity:

1. There's some past work[1] on authenticated Btrfs, where the whole 
filesystem is authenticated w/ a keyed hash algorithm. It's basically 
dm-integrity built directly into the filesystem, with none of the 
performance and complexity penalty. I think it makes a lot more sense 
to reuse Btrfs's already-existing hashing infrastructure with HMAC than 
to put a second layer of integrity checking under it. Perhaps pushing 
for that work to land in the kernel is a better use of time than 
working around dm-integrity's limitations? I'd like to hear your 
thoughts on this most.

2. Integrity-checking all the filesystems that will be mounted is 
infeasible. Here's two cases I can think of right off the bat:
- At some point, to do a system update, the ESP or the XBOOTLDR 
partition will be mounted by userspace. What if these filesystems are 
maliciously constructed to exploit the kernel? It's not possible to use 
any kind of integrity checking on these filesystems because they're 
read by things outside of the kernel (firmware, bootloader). Maybe the 
filesystem can be constructed to exploit the (notoriously poorly 
implemented) UEFI firmware itself!
- Any USB stick the user will plug into the computer *might* have a 
malicious filesystem on it. The only way to protect against this is to 
never mount USB sticks plugged into the device. Asking for an 
admin/root password will just be an annoyance and users will type it 
in. There's really no way around it; users will have to occasionally 
mount untrusted filesystems on their machine

3. What is dm-integrity protecting in the homed image? Assuming /home 
is protected from offline writes, there's no way an attacker can modify 
the contents of the loopback file anyways. Why layer dm-integrity on 
top of that?

[1]: 
<https://lore.kernel.org/linux-btrfs/20200428105859.4719-1-jth@kernel.org/>

Regards,
Adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20211202/b19649ca/attachment.htm>