On Wed, Dec 8, 2021, at 1:28 PM, Chris Murphy wrote:
On Wed, Dec 8, 2021 at 7:52 AM Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
>
> On Di, 07.12.21 15:39, Zbigniew Jędrzejewski-Szmek (zbyszek(a)in.waw.pl) 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.