Apparently on HyperV the measurement logs announce the hash algs in a
different order in the header than the records have them. Let's handle
this gracefully
Let's drop the "systemd-" prefix from the credential name. We do not
prefix credentials that way so far. Don't do so here either.
The name is not really API, it's not documented, hence change it now
where we still can.
Rather than adding more and more parameters to ask_password_auto(), let's
pass a structure of the fields that often are constant anyway.
This way, callers can fill in what they need, and we take the filled
structure which we can pass around internally as one.
This is in particular preparation for adding one more field in one of
the next commits.
So far credentials are a concept for system services only: to encrypt or
decrypt credential you must be privileged, as only then you can access
the TPM and the host key.
Let's break this up a bit: let's add a "user-scoped" credential, that
are specific to users. Internally this works by adding another step to
the acquisition of the symmetric encryption key for the credential: if a
"user-scoped" credential is used we'll generate an symmetric encryption
key K as usual, but then we'll use it to calculate
K' = HMAC(K, flags || uid || machine-id || username)
and then use the resulting K' as encryption key instead. This basically
includes the (public) user's identity in the encryption key, ensuring
that only if the right user credentials are specified the correct key
can be acquired.
The OVMF UEFI firmware is measuring PK and KEK when secure boot is
disabled, and those variables are absent. This can be checked via the
event log to see that there are extensions for PCR 7 associated with PK
and KEK events of type EV_EFI_VARIABLE_DRIVER_CONFIG.
When running the "lock-secureboot-policy" verb, pcrlock complains that
those variables are not found and refuse to generate the
240-secureboot-policy.pcrlock.d/generated.pcrlock file.
The "TCG PC Client Platform Firmware Profile Specification Version 1.05
Revision 23"[1] from May 7, 2021, in section "3.3.4.8 PCR[7] - Secure
Boot Policy Measurements", point 10.b:
If reading a UEFI variable returns UEFI_NOT_FOUND, platform firmware
SHALL measure the absence of the variable. The
UEFI_VARIABLE_DATA.VariableDataLength field MUST be set to zero and
UEFI_VARIABLE_DATA.VariableData field will have a size of zero.
This patch mark those variables to be marked as "synthesize empty",
generating the correct hash for those variables.
Signed-off-by: Alberto Planas <aplanas@suse.com>
Fix the path for the generated.pcrlock files for the cmdline and initrd
cases. Without it the tool complains with:
Failed to parse component file /var/lib/pcrlock.d/720-kernel-initrd.pcrlock, ignoring: Is a directory
Signed-off-by: Alberto Planas <aplanas@suse.com>
I am sorry, I totally forgot adding emojis reflecting the state of each
PCR. I hope I can do better in future, and hereby I'd like to rectify
the situation a bit.
Lennart Poettering
Alberto Planas
Gabríel Arthúr Pétursson
Mike Yuan
Frantisek Sumsal
Yu Watanabe