The SRK templates are defined by specification, so move the check for TPM
support to the tpm2_get_best_srk_template() function, and allow anyone to get
the ECC and RSA templates.
Also add test to verify the SRK templates are correct.
Let's be friendly in what we accept: whenever we define a JSON
structure, let's also allow decimal strings where we want an integer.
This patch purely replaces JSON_VARIANT_UNSIGNED by
_JSON_VARIANT_TYPE_INVALID in the various JsonDispatch[] tables, so that
we'll happily accept any type in json_dispatch(), so that
json_dispatch_uint64() and related tools can do their thing.
This does not switch over OCI (as a JSON structure not defined by us).
JSON famously is problematic with integers beyond 53 bits, because
JavaScript stores everything in double precision floating points.
Various implementations in other languages can deal with signed 64 bit
integers, and a few can deal with unsigned 64bit too (like ours).
Typically program that need more then 53 bit of accuracy encode integers
as decimal strings, to make sure that even if consumers can't really
process larger values they at least won't corrupt the data while passing
it along. This is also recommended by JSON-I (RFC 7493)
To maximize compatibility with other implementations let's add 1st class
parsing support for such objects in the json_dispatch() API.
This makes json_dispatch_uint64() and related calls parse such
integers-formatted-as-decimal-strings as uint64_t. This logic will only
be enabled if the "type" field of JsonDispatch is left unspecified (i.e.
set to negative/_JSON_VARIANT_TYPE_INVALID) though, hence alone does not
change anything in effect.
This purely is about consuming such values, whether we should genreate
them also is a discussion for a separate PR.
These helpers tpm2_seal_data()/tpm2_unseal_data() are useful for
sealing/unsealing data without any further semantics around them. This
is different from the existing tpm2_seal()/tpm2_unseal() which seal with
a specific policy and serialize in a specific way, as we use it for disk
encryption.
These new helpers are more generic, they do not serialize in a specific
way or imply policy, they are just the core of the sealing/unsealing.
(We should look into porting tpm2_seal()/tpm2_unseal() onto these new
helpers, but this isn#t trivial, since the classic serialization we use
uses a merged marshalling of private/public key, which we'd have to
change in one way or another)
This is the primary core of what pcrlock is supposed to do eventually:
maintain a TPM2 policy hash inside an NV index which we then can
reference via a PolicyAuthorizeNV expression to lock other objects
against it.
Note: we export these new symbols for now. A later commit in this PR
will make them static again. The only reason they are exported here is
to make sure gcc doesn't complain about unused static symbols, and I
really wanted to commit them in a separate commit.
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
I tried to get something similar upstream:
https://gitlab.com/cryptsetup/cryptsetup/-/issues/846
But no luck, it was suggested I use ELF interposition instead. Hence,
let's do so (but not via ugly LD_PRELOAD, but simply by overriding the
relevant symbol natively in our own code).
This makes debugging tokens a ton easier.
Sometimes it makes sense to hard kill a client if we die. Let's hence
add a third FORK_DEATHSIG flag for this purpose: FORK_DEATHSIG_SIGKILL.
To make things less confusing this also renames FORK_DEATHSIG to
FORK_DEATHSIG_SIGTERM to make clear it sends SIGTERM. We already had
FORK_DEATHSIG_SIGINT, hence this makes things nicely symmetric.
A bunch of users are switched over for FORK_DEATHSIG_SIGKILL where we
know it's safe to abort things abruptly. This should make some kernel
cases more robust, since we cannot get confused by signal masks or such.
While we are at it, also fix a bunch of bugs where we didn't take
FORK_DEATHSIG_SIGINT into account in safe_fork()
varlink_dispatch() is a simple wrapper around json_dispatch() that
returns clean, standards-compliant InvalidParameter error back to
clients, if the specified JSON cannot be parsed properly.
For this json_dispatch() is extended to return the offending field's
name. Because it already has quite a few parameters, I then renamed
json_dispatch() to json_dispatch_full() and made json_dispatch() a
wrapper around it that passes the new argument as NULL. While doing so I
figured we should also get rid of the bad= argument in the short
wrapper, since it's only used in the OCI code.
To simplify the OCI code this adds a second wrapper oci_dispatch()
around json_dispatch_full(), that fills in bad= the way we want.
Net result: instead of one json_dispatch() call there are now:
1. json_dispatch_full() for the fully feature mother of all dispathers.
2. json_dispatch() for the simpler version that you want to use most of
the time.
3. varlink_dispatch() that generates nice Varlink errors
4. oci_dispatch() that does the OCI specific error handling
And that's all there is.
If we have a DDI that contains only a /usr/ tree (and which is thus
combined with a tmpfs for root on boot) we previously would try to apply
idmapping to the tmpfs, but not the /usr/ mount. That's broken of
course.
Fix this by applying it to both trees.
Dan Streetman
Lennart Poettering
Antonio Alvarez Feijoo
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
Daan De Meyer
Yu Watanabe
Frantisek Sumsal
Sam Leonard
David Tardon