On Wed, Dec 8, 2021, at 1:28 PM, Chris Murphy wrote: > On Wed, Dec 8, 2021 at 7:52 AM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: >> >> On Di, 07.12.21 15:39, Zbigniew Jędrzejewski-Szmek (zbyszek@xxxxxxxxx) wrote: >> >> > Latest systemd versions have been getting some support for the low-level >> > parts, i.e. the low-level encrypted-secret storage. But we're missing the >> > upper parts, i.e. how to actually use and update the passwords. I didn't >> > even mention this, because we don't have a comprehensive story yet. >> > I think it'd be necessary to write some pam module and/or authentication >> > helper from scratch. It's probably not too much work, but nobody has >> > signed up to do this. >> >> So here's what I'd suggest: let's define a group (my suggestion: let's >> repurpose "wheel" for that) that has the effect that the passwords of >> any user in it are also accepted as password for the root user, >> implicitly. We'd have to add some small infra to collect these >> passwords, and encrypt/sign them with TPM2, then propagate to the ESP >> or to some EFI var or so, so that they can be honoured already in the >> initrd.I mean in addition this is tantamount to moving `/etc/shadow` into the tpm, right? > > I'm skeptical of any TPM2 dependency because systems still do not come > with them, in particular the significant minority of systems that are > not part of the "made for Windows" marketing program that compels > manufacturers to follow the Windows Hardware Compatibility Program. > And yes you can install Windows 11 without a TPM, it just won't be > preinstalled, and that make/model doesn't qualify for whatever Windows > marketing programs OEM's get for having certified hardware. That's > aside from the fact there's TPM 2.0 in hardware today that the kernel > doesn't support and likely won't ever support. Right. I am in favor of having tight integration with the TPM of course, but it can't be used exclusively. In particular, I think about half the posters in this thread are thinking of the desktop case, but the problem can easily happen on virtualized servers too - that's why we ship the bits we do in Fedora CoreOS. And we need to consider public and private cloud (e.g. OpenStack/vSphere) instances which were provisioned without UEFI, as well as ppc64le and s390x. And still today, the default for `virt-install` on x86_64 is BIOS. So I'll just re-surface my idea of having the bootloader either pass information about its "locked" state to the kernel and to systemd, or have some sort of more declarative easily parsable config file for this that systemd could read (i.e. not `grub.cfg`). The former seems better. Either way there's just one "source of truth" and admins who *do* want to lock the system against casual keyboard interactive changes don't need to do it in two places. _______________________________________________ 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
