On Mo, 04.07.22 11:32, Gerd Hoffmann (kraxel@xxxxxxxxxx) wrote: > Hi, > > > We have been working on building tools and filling gaps to make that > > workable reasonably in systemd upstream, and with a focus on > > Fedora. The difficulty is in both being able to prebuild everything > > but also keeping things somewhat modular and parameterizable. Because > > right now those are the primary reasons initrds are built on the > > installed host instead of Fedora: they contain local configuration and > > drivers. If we prebuild everything we must have model to > > replace these parts, without compromising security, and that's not > > rivial. > > Is all this this discussed somewhere in public? We'll have a session about that at Linux Plumbers Conference... There was a talk about it at devconf.cz: https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf > systemd-devel list maybe? That'd probably be the best place, yeah. > For virtual machines we need some way to make sure they actually run > the software we want them run, and it seems the options we have are: > > (1) finally plug that initrd hole, or > (2) use encrypted /boot > > ... where (2) feels more like a workaround for the unsigned initrd > problem and it also opens another can of worms like requiring luks > support in the boot loader. I find 2 very wrong, as it doesn't solve the actual issue (provides confidentiality, not actually authenticity). Moreover, as important as authentication is getting sane TPM measurements out of the whole thing, so that further policies can mapped to all this. > I guess you already have a list of the "local configuration" bits > which must be tackled? Obvious #1 is finding the root filesystem. > Should be solvable with discoverable partitions. A few days back > I've found a 7 (!) year old bug[1] of yours truly asking to support > that in anaconda, still in NEW state :( In a fully trusted environment I'd expect that the immutable root fs is pinned in the kernel image via the root hash. In a semi-trusted environment we should use GPT meta info to find the rootfs. This can either be the discovery partition sspec stuff (which I'd recommend), or if people insist a simple root=PARTLABEL=fedora or so on the kernel cmdline. An alternative is to use the systemd credential logic for this (this stuff: https://systemd.io/CREDENTIALS/). It allows encrypting and signing small blobs of info (so called "credentials") with the local TPM. They can then safely be stored on an untrusted medium (such as a ESP/boot partition), and are verified/decrypted on access. The "systemd-stub" EFI stub can automatically pick up such encrypted credentials from the ESP too, similar to the extension initrd images mentioned earlier in this thread. The credentials logic can also be used to for example pass a root pw for the initrd in a safe way. My expectation would be that by default we'd just use the GPT auto discovery stuff and for "pet" systems maybe also encode the root device with a credntial, but for "cattle" systems not bother. Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
