-1 was used everywhere, but -EBADF or -EBADFD started being used in various
places. Let's make things consistent in the new style.
Note that there are two candidates:
EBADF 9 Bad file descriptor
EBADFD 77 File descriptor in bad state
Since we're initializating the fd, we're just assigning a value that means
"no fd yet", so it's just a bad file descriptor, and the first errno fits
better. If instead we had a valid file descriptor that became invalid because
of some operation or state change, the other errno would fit better.
In some places, initialization is dropped if unnecessary.
The name "def.h" originates from before the rule of "no needless abbreviations"
was established. Let's rename the file to clarify that it contains a collection
of various semi-related constants.
Traditionally, TPM2 PCR policies are bound against literal PCR values,
which makes them hard to work with when updating software that is
measured into PCRs: each update will change the PCR values, and thus
break TPM2 policies of existing objects.
Let's improve the situation: let's allow signed PCR policies. Secrets
and other TPM2 objects can be associated with a public key that signs a
PCR policy. Thus, if the signed policy and the public key is presented,
access to the TPM2 object can be granted. This allows a less brittle
handling of updates: for example, whenever a kernel image is updated a
new signed PCR policy can be shipped along with it, signed by a private
key owned by the kernel vendor (ideally: same private key that is used
to sign the kernel image itself). TPM2 objects can then be bound to the
associated public key, thus allowing objects that can only be unlocked
by kernels of the same vendor. This makes it very easy to update kernels
without affecting locked secrets.
This does not hook up any of the consuming code (just passes NULL/0
everywhere). This is for later commits.
We currently have a convoluted and complex selection of which random
numbers to use. We can simplify this down to two functions that cover
all of our use cases:
1) Randomness for crypto: this one needs to wait until the RNG is
initialized. So it uses getrandom(0). If that's not available, it
polls on /dev/random, and then reads from /dev/urandom. This function
returns whether or not it was successful, as before.
2) Randomness for other things: this one uses getrandom(GRND_INSECURE).
If it's not available it uses getrandom(GRND_NONBLOCK). And if that
would block, then it falls back to /dev/urandom. And if /dev/urandom
isn't available, it uses the fallback code. It never fails and
doesn't return a value.
These two cases match all the uses of randomness inside of systemd.
I would prefer to make both of these return void, and get rid of the
fallback code, and simply assert in the incredibly unlikely case that
/dev/urandom doesn't exist. But Luca disagrees, so this commit attempts
to instead keep case (1) returning a return value, which all the callers
already check, and fix the fallback code in (2) to be less bad than
before.
For the less bad fallback code for (2), we now use auxval and some
timestamps, together with various counters representing the invocation,
hash it all together and provide the output. Provided that AT_RANDOM is
secure, this construction is probably okay too, though notably it
doesn't have any forward secrecy. Fortunately, it's only used by
random_bytes() and not by crypto_random_bytes().
Let's beef up our system credential game a bit, and explicitly import
creds from sd-stub, from qemu fw_cfg and the kernel cmdline and expose
them in the same way as those passed in from nspawn.
Specifically, this will imprt such credentials to
/run/credentials/@system (if the source can be trusted, as in the
qemu/kernel cmdline case) and /run/credentials/@encrypted (otherwise,
such as sd-stub provided ones).
Once imported we'll set the $CREDENTIALS_PATH env var for PID 1, like it
would be done by a container manager for the payload. (Conversely, we'll
also creat a symlink from /run/credentials/@system to whatever is set in
$CREDENTIALS_PATH in case we are invoked by a container manager, thus
providing a fixed path where system credentials are found).
This is supposed to be useful when generating credentials for immutable
initrd environments, where it is is relevant to support credentials even
on systems lacking a TPM2 chip.
With this, if `systemd-creds encrypt --with-key=auto-initrd` is used a
credential will be encrypted/signed with the TPM2 if it is available and
recognized by the firmware. Otherwise it will be encrypted/signed with
the fixed empty key, thus providing no confidentiality or authenticity.
The idea is that distributions use this mode to generically create
credentials that are as locked down as possible on the specific
platform.
Previously, when encrypting creds you could pick which key to use for
this via a 128bit ID identifying the key type, and use an all zero ID
for rquesting automatic mode.
Let's change this to use an explicitly picked 128bit ID for automatic
mode, i.e. something other than all zeros. This is in preparation for
adding one further automatic mode with slightly different semantics.
no change in behaviour.
Note that the new 128bit id is never written to disk but only used
internally to indicate a specific case.
Modify TPM2 authentication policy to optionally include an authValue, i.e.
a password/PIN. We use the "PIN" terminology since it's used by other
systems such as Windows, even though the PIN is not necessarily numeric.
The pin is hashed via SHA256 to allow for arbitrary length PINs.
v2: fix tpm2_seal in sd-repart
v3: applied review feedback
Let's switch from the low-level SHA256 APIs to EVP APIs. The former are
deprecated on OpenSSL 3.0, the latter are supported both by old
OpenSSL and by OpenSSL 3.0, hence are the better choice.
Fixes: #20775
Previously, we hardcoded use of ECC as primary keys, since they are much
faster (i.e. saving multiple seconds) to do TPM2 operations with. Alas,
not all TPM2 chips appear to support ECC. Bummer.
Let's hence add a fallback logic: if we can't create an ECC primary key,
use an RSA key, and store that fact away.
AFIU the security guarantees should be roughly the same, it's just that
RSA primary keys is so much slower to work with than ECC.
The primary key algorithm is used is stored in the JSON header of LUKS
disks, in a new field. If the field is absent we assume to use ECC, to
provide full compatibility with old systemd versions.
The primary key algorithm is stored in a new field in the credentials
file format (in fact, a previously unused zero space is used), too.
Hopefully, this should ensure that TPM2 support will "just work" on more
systems.
Fixes: #20361
Previously, we'd encode PCR policies strictly with the SHA256 PCR bank
set. However, as it appears not all hw implement those. Sad.
Let's add some minimal logic to auto-detect supported PCR banks: if
SHA256 is supported, use that. But if not, automatically fall back to
SHA1.
This then changes both the LUKS code, and the credentials code to
serialize the selected bank, along with the rest of the data in order to
make this robust.
This extends the LUK2 JSON metadata in a compatible way. The credentials
encryption format is modified in an incompatible way however, but given
that this is not part of any official release should be OK.
Fixes: #20134
This is preparation for adding encryption support to the credentials
logic, and we thus would like to add more deps. Let's hence move things
from src/basic/ to src/shared, so that we can rely on the OpenSSL
utilities already in src/shared.
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Ludwig Nussel
Jason A. Donenfeld
Grigori Goronzy
Luca Boccassi