On 02/12/2021 21:24, Adrian Vovk wrote:
Hello Wol,
Please, read the blog post I'm responding to for context to what I'm
saying: https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html
dm-integrity is NOT ABOUT authentication
dm-integrity provides authentication when configured to use
sha256-hmac. I am not confusing dm-verity with dm-integrity.
Yup. Reading the blog makes it clearer ...
So HMAC provides integrity guarantees that it was written by users who
knew the code, so I guess that is authentication.
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.
Well that's my point. A clever attacker can modify the filesystem
outside of the kernel and exploit a kernel vulnerability. The point of
putting dm-integrity on the rootfs (in hmac mode) is to prevent the
rootfs from being modified offline. My point is that it's entirely
possible to maliciously modify other filesystems that *will* be
mounted and *cannot* us dm-integrity
Understood ...
You should always run dm-integrity on bare metal.
Lennart was proposing to use dm-integrity (in HMAC mode) inside of the
loopback image to verify that the filesystem inside of the image was
not maliciously modified to hijack the kernel. My argument was that,
given that the filesystem the image is stored on is authenticated, why
does the content of the image have to be authenticated? As I've
pointed out in a previous email, layering instances of dm-integrity on
top of each other is catastrophic for write performance
Seeing as it's a /home/user image I'd agree with you. If it's a rootfs,
then that image needs to guarantee that the file-system hasn't been
altered outside its own purview.
The only thing I don't understand is why layering dm-integrity in a loop
device on top of dm-integrity on a real disk should necessarily hammer
write performance. I can understand it chewing up ram cache and cpu, but
it shouldn't magnify real writes that much.
Cheers,
Wol
