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

[Wol]

On 02/12/2021 06:11, Adrian Vovk wrote:
> 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.

Hmmm. I use dm-integrity. I use ext4 not btrfs. And anyways, 
dm-integrity is NOT ABOUT authentication, so using btrfs's 
authentication capabilities is in addition to, not instead of, dm-integrity.

Are you confusing (like I did) dm-verity and dm-integrity?
> 
> 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).

What if they're WRITTEN by things outside of the kernel? At which point, 
when the kernel tries to read it, things will go well pear-shaped for 
the system. So if an attacker gains access to the hard disk, modifies 
it, and waits for linux to read it, he's going to have a loonnggg wait :-)

> 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?
> 
What dm-integrity is doing is protecting whatever has been written to 
disk. If it's been written outside of dm-integrity, it won't read inside 
of dm-integrity. You should always run dm-integrity on bare metal.

My setup is ext4 over lvm over raid-5 over dm-integrity over spinning 
rust. So provided it's only the one hard drive (and I spot it in time), 
I don't care what happens to that drive. Something could scribble all 
over my filesystem corrupting the hell out of, and all I have to do is 
run a scrub and it's fixed. That would destroy your standard raid 5 - it 
has one extra bit of recovery information, and if it's missing two bits 
of information (a block is scrambled, and it doesn't know which block) 
then you're stuffed. What dm-integrity does is convert your scrambled 
block into a lost block, so raid now has just one piece of missing 
information - the lost block.

Cheers,
Wol