The new "password-cache" option allows customizing behavior of the
ask-password module in regards to caching credentials in the kernel
keyring. There are 3 possible values for this option:
* read-only - look for credentials in kernel keyring before asking
* on - same as read-only, but also save credentials input by user
* off - disable keyring credential cache
Currently the cache is forced upon the user and this can cause issues.
For example, if user wants to attach two volumes with two different
FIDO2 tokens in a quick succession, the attachment operation for the
second volume will use the PIN cached from the first FIDO2 token, which
of course will fail and since tokens are only attempted once, this will
cause fallback to a password prompt.
Currently, if user doesn't specify a key file, /etc/cryptsetup-keys.d/
and /run/cryptsetup-keys.d/ will be searched for a key file with name
matching the volume name. But current implementation has an important
flaw. When the auto-discovered key is a socket file - it will read the
key only once, while the socket might provide different keys for
different types of tokens. The issue is fixed by trying to discover the
key on each unlock attempt, this way we can populate the socket bind
name with something the key provider might use to differentiate between
different keys it has to provide.
systemd-cryptsetup supports a FIDO2 mode with manual parameters, where
the user provides all the information necessary for recreating the
secret, such as: credential ID, relaying party ID and the salt. This
feature works great for implementing 2FA schemes, where the salt file
is for example a secret unsealed from the TPM or some other source.
While the unlocking part is quite straightforward to set up, enrolling
such a keyslot - not so easy. There is no clearly documented
way on how to set this up and online resources are scarce on this topic
too. By implementing a straightforward way to enroll such a keyslot
directly from systemd-cryptenroll we streamline the enrollment process
and reduce chances for user error when doing such things manually.
When in FIDO2 mode with manual parameters, i.e. when not reading the
parameters off the LUKS2 header, the current behavior in regards to PIN,
UP and UV features is to default to v248 logic, where we use PIN + UP
when needed, and do not configure UV at all. Let's allow users to
configure those features in manual mode too.
This is preparation for making our Varlink API a public API. Since our
Varlink API is built on top of our JSON API we need to make that public
first (it's a nice API, but JSON APIs there are already enough, this is
purely about the Varlink angle).
I made most of the json.h APIs public, and just placed them in
sd-json.h. Sometimes I wasn't so sure however, since the underlying data
structures would have to be made public too. If in doubt I didn#t risk
it, and moved the relevant API to src/libsystemd/sd-json/json-util.h
instead (without any sd_* symbol prefixes).
This is mostly a giant search/replace patch.
If we couldn't unlock a device with the chosen unlock path, let's not
fall back to the lowest one right away, but only flush out one path, and
try the next.
Fixes: #30425
Follow-up-for: #30185
Alternative-to: #33183
- drop unnecessary SYNTHETIC_ERRNO() when the logger does not propagate
error code,
- drop unnecessary '%m' in error message when the error code is
specified with SYNTHETIC_ERRNO(),
- add missing full stop at the end of log message,
- use RET_GATHER(),
- add missing ", ignoring.",
- upeercase the first letter, etc., etc...
We so far just print a short log message that is not very useful, let's
add some recognizable error codes, and output better log messages if we
can't get TPM stuff to work.
Fixes: #31925
This bool controls whether we should interactively ask for a password,
which is pretty much what the ask_password-api.c APIs are about. Hence,
just make the bool a flag in AskPasswordFlags enum, and use it
everywhere.
This still catches the flag early in upper levels of the codebase,
exactly as before, but if the flag is still present in the lower layers
it's also handled there and results in ENOEXEC if seen.
This is mostly an excercise in simplifying our ridiculously long
function call parameter lists a bit.
Let's make sure that when cryptenroll asks for the TPM2 or FIDO2 token
PIN it uses cryptenroll.* credential namespace, and cryptsetup uses
cryptsetup.*.
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.
cryptsetup 2.7.0 adds feature to link effective volume key in custom
kernel keyring during device activation. It can be used later to pass
linked volume key to other services.
For example: kdump enabled systems installed on LUKS2 device.
This feature allows it to store volume key linked in a kernel keyring
to the kdump reserved memory and reuse it to reactivate LUKS2 device
in case of kernel crash.
Previously only the first entered passphrase would be used. Add the ability to check all the passwords entered by the user. The total number of passwords entered is still limited by passphrase entry limit.
The pkcs11 uri is no set if the smart card is not inserted while using
`pkcs11-uri=auto` with libcryptsetup plugins.
```
> systemd-cryptsetup attach cr_data /dev/sda1 - pkcs11-uri=auto
Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/sda1.
Security token (null) not present for unlocking volume Linux filesystem (cr_data), please plug it in.
```
The pkcs11 cryptsetup token module is a bit different from the tpm2 +
fido2 ones: it asks for the PIN itself, rather than bubbling up a
request to get a PIN. That's because it might need multiple, and because
we don't want to destroy a the pkcs11 session half-way and thus risk
increasing pin counters.
Hence, we sometimes ask for PINs from our code, rather than let the
libcryptsetup caller do that. So far we didn't pass the AskPasswordFlags
field down into the module though. Fix that.
Fixes: #28665
if we allow cryptsetup to activate a volume via token plugin we never
get access to the volume key, which we'd like to measure. Hence disable
token plugins in that case.
(I tempted to say we probably should disable them entirely, and only use
them if classic cryptsetup is used, but that's a discussion for another
day.)
Fixes: #29790
Because most TPM2 functions here are 'library-like' functions, they should be
at debug level, not error level.
The only functions not reduced to logging at debug are tpm2_list_devices(),
since it is expected to print output, and the tpm2_parse_pcr_argument_*()
functions, since the system-wide parse_*_argument() functions generally log at
error level.
Let's say "uki" rather than "stub", since that is just too generic, and
we shouldn't limit us to our own stub anyway, but generally define a
concept of a "measured UKI", which is a UKI that measures its part to
PCR 11.
This is mostly preparation for exposing this check to the user via
ConditionSecurity=.
All public programs are expected to have that. The --help output is adjusted to
follow the usual style (highlighting, listing of options). The OPTIONS
positional argument is renamed to "CONFIG", because we now also have "OPTIONS…"
to describe the non-positional options.
Previously we only logged our measurements to the journal. This is not a
great solution though, since regular logs are subject to rotation, which
is something we really cannot have for measurements (as it means we can
never reproduce the PCR values from the data). Hence, let's maintain an
explicit log.
Ideally, we'd just use the TCG Canonical Event Log format 1:1
(https://trustedcomputinggroup.org/resource/canonical-event-log-format/).
However it's not a perfect fit fo us, for various reasons. But let's
follow it (in its JSON incantation) as closely at it makes sense, so
that it can easily be converted to the full format by programs consuming
it.
Code comments explain where we deviate from the TCG CEL-JSON, and what
to do about it when reading the data.
I always found it confusing that most of our TPM related definitions are
in tpm2-util.h, but the PCR names in tpm-pcr.h, without the "2". Let's
fix that and make this systematic, in particular as the definitions in
the file all start with TPM2_ already.
No code flow changes, just some renaming.
We so far maintained two places for symboic names for PCRs. One in
tpm2-util.h and one in tpm-pcr.h.
Let's unify this into one, i.e. move the full list from tpm2-util.h into
tpm-pcr.h, replacing the short list placed so far there.
Systematically prefix the definitions with TPM2_ or tpm2_, to follow how
we do this for all other defines in this context.
No change in behaviour, just unification of tables.
In order to allow users to specify expected PCR values, change the
tpm2_parse_pcr_argument() to parse the text argument into an array of
Tpm2PCRValue objects, which provide not only the selected PCR indexes, but also
(optionally) the hash algorithm and hash value for each PCR index.
Add a new struct that can represent a PCR index, hash, and value all
together. This replaces code (e.g. the tpm2_pcr_read() parameters) that
required using both a TPML_PCR_SELECTION as well as array of TPM2B_DIGEST
entries, which was difficult to correlate the selection hash/index to each
digest.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_NOT_SUPPORTED() is the
value returned by find_tpm2_auto_data() which is not expected to return
any positive values, but let's be consistent anyway and move the
ERRNO_IS_NOT_SUPPORTED() invocation to the branch where
the return value is known to be negative.
Remove _cleanup_tpm2_context_ and _cleanup_tpm2_handle_ macros, replacing their
use with _cleanup_(tpm2_context_unrefp) and _cleanup_(tpm2_handle_freep),
respectively.