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
