On Fr, 27.09.19 13:17, Alberto Ruiz (ar...@redhat.com) wrote: > > Hmm, why do you need a correct initrd in the early boot? I can see two > > reasons: > > > > 1. full disk encryption with the user typing in the password on the > > kbd. But isn't the answer to this to link the root OS to the tpm > > instead, and use user-keyed crypto only for $HOME? The OS itself > > doesn't need to be protected after all, everbody should have the > > same files there anyway, it's $HOME that needs protection. > > > > Some counterarguments here: > - The TPM does not protect you from someone stealing your entire laptop and > booting from external media,
What's your attack scenario? I mean, what's wrong with the attacker being able to do that, as long as they cannot modify the OS nor can read or modify your $HOME? Not following on this one? > - There are plenty of systems out there without a TPM module that Fedora > cares about Well, sure, but I isn't it OK that platforms with fewer hw features have more minimal functionality? Would anyone expect otherwise? > - A key password entry is still a fallback if your motherboard gets fried > and you move your hardrive to a new laptop. I mean, this sounds like needless complexity, no? As long as you can still access your $HOME the OS shouldn't need to be saved. I mean, that's the idea of Atomic OS that it is immutable, and everywhere identical and thus can be downloaded anytime form the internet without losing context. > - /var may contain pretty sensitive data these days too (SSSD caches, > libvirt system wide vms, docker images...). That can just fine be unlocked during regular boot, if this is desirable, i.e. long after the kbd map is installed. > That said, I am not a big fan of having grub dynamically injecting cmdline > args, this can be a challenge to measure and sign the command line to > implement a trusted boot path using the TPM in the future. (I guess systemd > would need to take care of resealing the cmdline args when localectl > changes the efi var and detects the cmdline is measured). Well, i'd put the EFI outside of any cryptographic validation. I mean, if anyone can write bogus vars, then they could also replace the validation certs in the firmware i guess, so I am not sure we have to be careful with them. Moreover, I think a validity check in the sense of "do we actually have a keymap matching this name" should be sufficient. Sure, an attacker might then be able to pull off giving you a japanese keymap for a bit, but I doubt this is so bad... Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
