If we operate in "offline" mode, i.e. know the device key, then we will
not have a TPM2 connection, hence don't try to read the PCR bank to use form
it.
We don't need it anyway because we are not going to test unseal things.
Fixes: #33855
So far you had to pick:
1. Use a signed PCR TPM2 policy to lock your disk to (i.e. UKI vendor
blesses your setup via signature)
or
2. Use a pcrlock policy (i.e. local system blesses your setup via
dynamic local policy stored in NV index)
It was not possible combine these two, because TPM2 access policies do
not allow the combination of PolicyAuthorize (used to implement #1
above) and PolicyAuthorizeNV (used to implement #2) in a single policy,
unless one is "further upstream" (and can simply remove the other from
the policy freely).
This is quite limiting of course, since we actually do want to enforce
on each TPM object that both the OS vendor policy and the local policy
must be fulfilled, without the chance for the vendor or the local system
to disable the other.
This patch addresses this: instead of trying to find a way to come up
with some adventurous scheme to combine both policy into one TPM2
policy, we simply shard the symmetric LUKS decryption key: one half we
protect via the signed PCR policy, and the other we protect via the
pcrlock policy. Only if both halves can be acquired the disk can be
decrypted.
This means:
1. we simply double the unlock key in length in case both policies shall
be used.
2. We store two resulting TPM policy hashes in the LUKS token JSON, one
for each policy
3. We store two sealed TPM policy key blobs in the LUKS token JSON, for
both halves of the LUKS unlock key.
This patch keeps the "sharding" logic relatively generic (i.e. the low
level logic is actually fine with more than 2 shards), because I figure
sooner or later we might have to encode more shards, for example if we
add further TPM2-based access policies, for example when combining FIDO2
with TPM2, or implementing TOTP for this.
If the policy hash is empty we shouldn't return "0" from
search_policy_hash(), because that is understood as slot index 0, but
that's unlikely to match the policy.
Hence, return -ENOENT instead, indicating that we can't find a matching
slot.
Use these helpers whenever appropriate. Drop separate string checks,
since these helpers already do them anyway.
No actual code change, just a rework to make use of a nice helper we
have already.
This is a lot of stuff, and sometimes quite wild, let's turn this into
its own header.
All stuff color-related that just generates sequences is now in
ansi-color.h (no .c file!), and everything more complex that
probes/ineracts with terminals remains in termina-util.[ch]
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.
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.
We so far derived the PCR bank to use from the PCR values specified fr
literal PCR binding. However, when that's not used then we left the bank
uninitialized – which will break if signed PCR binds are used (where we
need to pick a bank too after all).
Hence, let's explicitly pick a bank to use if literal PCR values are not
used, to make things just work.
Fixes: #32946
We currently do not support pcrlock policies and signed PCR policies in
combination. Hence, when we auto-discover both, let's disable signed PCR
policies if pcrlock is available too (simple because that covers more
ground).
Fixes: #32565
- 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...
With 1df4b21abd we started to default to
enrolling into the LUKS device backing the root fs if none was specified
(and no wipe operation is used). This changes to look for /var/ instead.
On most systems /var/ is going to be on the root fs, hence this change
is with little effect.
However, on systems where / and /var/ is separate it makes more sense to
default to /var/ because that's where the persistent and variable data
is placed (i.e. where LUKS should be used) while / doesn't really have
to be variable, could as well be immutable, or ephemeral. Hence /var/
should be a safer default.
Or to say this differently: I think it makes sense to support systems
with /var/ being on / well. I also think it makes sense to support
systems with them being separate, and /var/ being variable and
persistent. But any other kind of system I find much less interesting to
support, and in that case people should just specify the device name.
Also, while we are at it, tighten the checks a bit, insist on a dm-crypt
+ LUKS superblock before continuing.
And finally, let's print a short message indicating the device we
operate on.
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.*.
similar as the previous commit, let's clean up the credential name we
use. Use home.token-pin in case of homectl, and cryptenroll.pkcs11-pin
in case of cryptenroll.
The TPM2 enrollment is the only of the three token enrollments where the
user picks a PIN at enrollment time (the others have a PIN set for the
token, not for the enrollment). Let's make sure it uses a different
credential for retrieving this PIN, in order to make sure people can
programmatically change PINs via credentials (in which case they need to
supply both).
Querying a fido2 PIN via askpw for enrolling is currently used in two
places: cryptenroll and homectl. So far we sloppily used the same fixed
credential name "fido2-pin" in both cases. Let's tweak that and make the
credential name match the other credentials cryptenroll or home query,
i.e. using the cryptenroll.* and home.* namespaces.
This is particular done in light of #31370, which wants to make the
credential name public. We really should get the name in order before
making it public.
The "id" is used in the askpw protocol to recognize password prompts, in
case a service is replying to them and needs some id. Previously we set
an incorrect id, the one of cryptsetup. Fix that.
(I guess the id is not used much, it comes from a time where we had no
credentials, and thus some people wanted to supply passphrases
programmatically rather interactively. The usecase is probably gone, but
we should still set some valid id I guess.)
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.
systemd-cryptenroll uses the READ_FULL_FILE_CONNECT_SOCKET flag when
reading the keyfile to also allow reading it from a socket. But it also
sets the offset to 0, causing an unnecessary seek to the beginning of
the newly opened keyfile and disables socket support again, as these do
not support seeking.
Disable seeking entirely to remove the unneeded seek and restore support
for reading the keyfile from a socket again as with systemd-cryptsetup.
cryptenroll accepts only PKCS#11 URIs that match both a certificate and a private key in a token.
This patch allows users to provide a PKCS#11 URI that points to a certificate only, and makes possible to use output of some PKCS#11 tools directly.
Internally the patch changes 'type=cert' in the provided PKCS#11 URI to 'type=private' before storing in a LUKS2 header.
Fixes: #23479
Daan De Meyer
Yu Watanabe
Lennart Poettering
Kamil Szczęk
Sam Leonard
Mike Yuan
Luca Boccassi
Ludwig Nussel
Felix Riemann
Vladimir Stoiakin
Gabríel Arthúr Pétursson
Cristian Rodríguez