Re: Make systemd-localed modify the kernel commandline for the initrd keymap?

[Lennart Poettering <mzerqung@xxxxxxxxxxx>]

On Fr, 27.09.19 13:17, Alberto Ruiz (aruiz@xxxxxxxxxx) 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel