Poettering: Authenticated Boot and Disk Encryption on Linux

AFAIK there's still longstanding issues with dm-integrity around the atomicity of writes done by the filesystem; I think the current design with a doubles the amount of I/O. e.g. https://www.reddit.com/r/DataHoarder/comments/d45tar/dmin...

That's probably fine for `/etc`, but likely to be quite noticeable for `/var` in any nontrivial setup. Most data center deployments that already have physical security are going to want to keep performance I'd guess. Probably this would also be a notable hit for "local workstation" flows where you're e.g. doing e.g. compilation; cloning git repos, pulling build containers, etc. Splitting some of this stuff into separate encrypted-but-not-authenticated volumes gets into a lot of nuanced tradeoffs.

In the end, I would agree this type of setup probably deserves to be an available checkbox in most general-purpose Linux system installers. And with my CoreOS hat on, installer = ignition config applied on firstboot, so it *can* work in IaaS clouds too, even if I doubt most people would want it there since "evil maid" types attack in IaaS generally either require root on the hypervisor or root account credentials, in which case you have much bigger problems.

Anyways, on the larger topic I have this blog entry which I think still applies:
https://blog.verbum.org/2017/06/12/on-dm-verity-and-opera...

Basically it's important to keep in mind here that this proposal does *not* have the property that if your system is compromised remotely (e.g. web browser exploit), then it's still easy for an attacker to persist code in all the usual places (`~/.bashrc`, `/etc/systemd/system`, `~/.local/share/containers`, `/var/lib/containers`, any VM images you have, etc.).

You didn't mention e.g. Fedora CoreOS which *is* shipping image based updates, but not authenticated (e.g. dm-verity) right now because to me it's really important to preserve the ability to e.g. roll back just the kernel on a specific machine because you hit an issue after an update. ( https://github.com/coreos/fedora-coreos-tracker/issues/940 is just one recent example )

Having a dm-verity for the rootfs in theory can make it easier to reprovision if you suspect compromise, but the thing is if you *do* suspect compromise I think it's generally always going to be better to just re-install the entire thing from trusted USB key or equivalent. (And then of course, for general purpose PCs and equivalent there's the whole problem of UEFI malware and flaws in vendor firmware...)

What makes a lot of sense to me is supporting a flow where (as my previous blog mentions) *everything* (OS, OS configuration, apps) are rolled into a big dm-verity or equivalent and there is no mechanism to persist code across reboot. There are people that are doing this for embedded devices. But I have difficulty imagining this for a workstation (dealing with things like `~/.bashrc`), and for the datacenter use case it's nuanced; the hard part there again I think is things like "OK we need to test this kernel on this specific server" and how the signing process works and validating that it's easy and predictable to build a new image in the exact state, just with that kernel override and such.