fido2_generate_hmac_hash() sets req->keyring to "fido2-pin" when
calling ask_password_auto(), suggesting that a key by this name
can be read from the kernel keyring. But the keyring is never
opened because the ASK_PASSWORD_ACCEPT_CACHED flag is not set.
Set ASK_PASSWORD_ACCEPT_CACHED to allow automated / scripted
setup of encrypted volumes with FIDO2. If the PIN turns out to
be invalid, clear ASK_PASSWORD_ACCEPT_CACHED to avoid retrying
and possible lockout.
Let's "spoil" access to TPM secrets when we boot into these two modes.
This matters in particular for storagetm: if the host gets exploited
while booted into storage target mode any secrets kept by the TPM might
remain accessible otherwise. By measuring a new "phase" word into PCR 11
we "blow the fuse" however on this boot.
Preparation for adding offline signing support. Some additional
features and fixes are included as well:
- We make sure to add an empty SMIMECAP attribute instead of a populated
one to mimick pesign more.
- We switch to PKCS7_dataFinal() instead of PKCS7_final() as all that the
latter does is an unnecessary copy before calling PKCS7_dataFinal().
- We add support for passing in the signing time via $SOURCE_DATE_EPOCH.
Let's make sure that the moment where factory reset is requested is
visible in the TPM PCR state, so that access to secrets is terminated.
This is particulary interesting when the system is booted with
systemd.unit=factory-reset.target on the kernel command line, requesting
a factory reset on the following boot. The preparations done in
userspace should already lose access to the TPM in that case.
storagetm mode means we we are network accessible. let's lock down
access to TPM secrets in this case: let's measure a pcr "phase" string
into PCR 11.
This is good as it means that if we are exploited in this state FDE
secrets protected by TPM are likely to remain protected, since the PCR
values wouldn't allow access.
In 2cc58b6c8a and related we established
rules on naming certs/public-keys/private-keys:
*-public-key.pem
*-private-key.pem
*-certificate.pem
Let's follow that naming in repart's man page too.
Follow-up for 3bd28bf721
SERVICE_RELOAD_SIGNAL state can only be reached via explicit reload jobs,
and we have a clear distinction between that and plain RELOADING=1
notifications, the latter of which is issued by clients doing reload
outside of our job engine. I.e. upon SERVICE_RELOAD_SIGNAL + RELOADING=1
we don't propagate reload jobs again, since that's done during transaction
construction stage already. The handling of combined RELOADING=1 + READY=1
so far is bogus however, as it tries to propagate duplicate reload jobs.
Amend this by following the logic for standalone RELOADING=1.
When a user logs into a non-default area we give them a private
$HOME for that area (that's what 'area' is supposed to be after all). We
so far left $XDG_RUNTIME_DIRECTORY as it was. Let's change that and
mirror the subdirectory logic there too.
Why? $XDG_RUNTIME_DIR is generally the place where AF_UNIX sockets are
bound that can be used to connect to per-user services. (in particular
all those which are behind D-Bus.) If we don't patch $XDG_RUNTIME_DIR
like this then this means all the backing services will use the main
area, which is problematic (since clients and services will disagree on
$HOME), and makes it impossible to support the area concept for
graphical logins properly.
This does not actually make graphical logins work, but it at least makes
them fail cleanly. That's because this patch alone won't make sure a
per-area service manager/dbus instance is invoked automatically. That
however can be added later, in a patch to logind.
Let's tweak update_environment() a bit: instead of being a NOP when no
value is specified, let's actively unset the specified environment
variable if it is set.
This shouldn't change much, since for the cases we call the function so
far the env vars in question should not be set before us in a way we'd
set them differently. However, this is nice preparation for later, as we
can make use of this for XDG_AREA which we might want to unset if we
consider the area dir invalid.
Let's move pam_systemd_home before pam_unix in the authentication hook.
Since a while we are exposing shadow entries for homed log entries via
NSS. This means that pam_unix now potentially has enough data for
authenticating a user on its own, without letting pam_systemd_home do
that. This is superficially OK, but also means that authentication will
always go via password, even if pkcs11/fido2 is registered.
Let's move this around, but be careful about it: let's list the precise
errors which we think are enough to terminating further PAM processing,
so that pam_unix comes into control in all cases where it's not clear
that pam_systemd_home owns the user record.
This previously wasn't visible to me, because on Fedora until authselect
1.5.1 (released earleir this year) the NSS shadow stuff was not enabled.
This does the same also for the "account" stack, except that the order
there already was as we want it.
Finally, shorten the account stack, by just requiring pam_unix.so and
dropping pam_permit.so, because it doesn't really serve much purpose
(and Fedora doesn't use it by default either.)
This has been depracted since v254 (2023). Let's kill it for
good now, it has been long enough with 2y. Noone has shown up who wants
to keep it. And given it doesn't work in SB world anyway, and is not
measured is quite problematic security wise.
mkosi now supports -R to rerun build scripts without rebuilding the
image so let's document that instead of the current hack to prevent
the rebuild by changing the output format.
Let's in particular log an even if a device name is too long for the
btrfs ioctl structure, instead of truncating it (which could
theoretically reference a different device).
mkosi now supports -R to rerun build scripts without rebuilding the
image so let's document that instead of the current hack to prevent
the rebuild by changing the output format.
Follow-up for 7f6af95dab
- Allocate internal buf on the stack, memdup() only at the end.
This ensures we're able to handle OOM gracefully, i.e.
return -EAGAIN on OOM while still emptying socket buffer.
- Do not treat empty notify message as error.
- Raise log level since all callers log loudly anyway.