linux-stable.git/security/keys, branch linux-5.17.y

KEYS: trusted: tpm2: Fix migratable logic

2022-06-14T16:41:45+00:00

commit dda5384313a40ecbaafd8a9a80f47483255e4c4d upstream.

When creating (sealing) a new trusted key, migratable
trusted keys have the FIXED_TPM and FIXED_PARENT attributes
set, and non-migratable keys don't. This is backwards, and
also causes creation to fail when creating a migratable key
under a migratable parent. (The TPM thinks you are trying to
seal a non-migratable blob under a migratable parent.)

The following simple patch fixes the logic, and has been
tested for all four combinations of migratable and non-migratable
trusted keys and parent storage keys. With this logic, you will
get a proper failure if you try to create a non-migratable
trusted key under a migratable parent storage key, and all other
combinations work correctly.

Cc: stable@vger.kernel.org # v5.13+
Fixes: e5fb5d2c5a03 ("security: keys: trusted: Make sealed key properly interoperable")
Signed-off-by: David Safford 
Reviewed-by: Ahmad Fatoum 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman

KEYS: trusted: Avoid calling null function trusted_key_exit

2022-04-08T11:57:37+00:00

[ Upstream commit c5d1ed846e15090bc90dfdaafc07eac066e070bb ]

If one loads and unloads the trusted module, trusted_key_exit can be
NULL. Call it through static_call_cond() to avoid a kernel trap.

Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
Signed-off-by: Dave Kleikamp 
Cc: Sumit Garg 
Cc: James Bottomley 
Cc: Jarkko Sakkinen 
Cc: Mimi Zohar 
Cc: David Howells 
Cc: James Morris 
Cc: "Serge E. Hallyn" 
Cc: linux-integrity@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Sasha Levin

KEYS: trusted: Fix trusted key backends when building as module

2022-04-08T11:57:37+00:00

[ Upstream commit 969a26446bcd142faedfe8c6f41cd7668596c1fa ]

Before this commit the kernel could end up with no trusted key sources
even though both of the currently supported backends (TPM and TEE) were
compiled as modules. This manifested in the trusted key type not being
registered at all.

When checking if a CONFIG_… preprocessor variable is defined we only
test for the builtin (=y) case and not the module (=m) case. By using
the IS_REACHABLE() macro we do test for both cases.

Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
Reviewed-by: Jarkko Sakkinen 
Reviewed-by: Ahmad Fatoum 
Reviewed-by: Sumit Garg 
Signed-off-by: Andreas Rammhold 
Tested-by: Ahmad Fatoum 
Signed-off-by: Ahmad Fatoum 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Sasha Levin

KEYS: fix length validation in keyctl_pkey_params_get_2()

2022-04-08T11:57:16+00:00

commit c51abd96837f600d8fd940b6ab8e2da578575504 upstream.

In many cases, keyctl_pkey_params_get_2() is validating the user buffer
lengths against the wrong algorithm properties.  Fix it to check against
the correct properties.

Probably this wasn't noticed before because for all asymmetric keys of
the "public_key" subtype, max_data_size == max_sig_size == max_enc_size
== max_dec_size.  However, this isn't necessarily true for the
"asym_tpm" subtype (it should be, but it's not strictly validated).  Of
course, future key types could have different values as well.

Fixes: 00d60fd3b932 ("KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]")
Cc:  # v4.20+
Signed-off-by: Eric Biggers 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman

security: DH - use KDF implementation from crypto API

2021-11-26T05:25:17+00:00

The kernel crypto API provides the SP800-108 counter KDF implementation.
Thus, the separate implementation provided as part of the keys subsystem
can be replaced with calls to the KDF offered by the kernel crypto API.

The keys subsystem uses the counter KDF with a hash primitive. Thus,
it only uses the call to crypto_kdf108_ctr_generate.

Signed-off-by: Stephan Mueller 
Acked-by: Mat Martineau 
Signed-off-by: Herbert Xu

security: DH - remove dead code for zero padding

2021-11-26T05:25:17+00:00

Remove the specific code that adds a zero padding that was intended
to be invoked when the DH operation result was smaller than the
modulus. However, this cannot occur any more these days because the
function mpi_write_to_sgl is used in the code path that calculates the
shared secret in dh_compute_value. This MPI service function guarantees
that leading zeros are introduced as needed to ensure the resulting data
is exactly as long as the modulus. This implies that the specific code
to add zero padding is dead code which can be safely removed.

Signed-off-by: Stephan Mueller 
Acked-by: Mat Martineau 
Signed-off-by: Herbert Xu

ucounts: Move get_ucounts from cred_alloc_blank to key_change_session_keyring

2021-10-20T15:34:20+00:00

Setting cred->ucounts in cred_alloc_blank does not make sense.  The
uid and user_ns are deliberately not set in cred_alloc_blank but
instead the setting is delayed until key_change_session_keyring.

So move dealing with ucounts into key_change_session_keyring as well.

Unfortunately that movement of get_ucounts adds a new failure mode to
key_change_session_keyring.  I do not see anything stopping the parent
process from calling setuid and changing the relevant part of it's
cred while keyctl_session_to_parent is running making it fundamentally
necessary to call get_ucounts in key_change_session_keyring.  Which
means that the new failure mode cannot be avoided.

A failure of key_change_session_keyring results in a single threaded
parent keeping it's existing credentials.  Which results in the parent
process not being able to access the session keyring and whichever
keys are in the new keyring.

Further get_ucounts is only expected to fail if the number of bits in
the refernece count for the structure is too few.

Since the code has no other way to report the failure of get_ucounts
and because such failures are not expected to be common add a WARN_ONCE
to report this problem to userspace.

Between the WARN_ONCE and the parent process not having access to
the keys in the new session keyring I expect any failure of get_ucounts
will be noticed and reported and we can find another way to handle this
condition.  (Possibly by just making ucounts->count an atomic_long_t).

Cc: stable@vger.kernel.org
Fixes: 905ae01c4ae2 ("Add a reference to ucounts for each cred")
Link: https://lkml.kernel.org/r/7k0ias0uf.fsf_-_@disp2133
Tested-by: Yu Zhao 
Reviewed-by: Alexey Gladkov 
Signed-off-by: "Eric W. Biederman"

trusted-keys: match tpm_get_ops on all return paths

2021-05-12T19:36:37+00:00

The `tpm_get_ops` call at the beginning of the function is not paired
with a `tpm_put_ops` on this return path.

Cc: stable@vger.kernel.org
Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs")
Reported-by: Dan Carpenter 
Signed-off-by: Ben Boeckel 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen

KEYS: trusted: Fix memory leak on object td

2021-05-12T19:36:36+00:00

Two error return paths are neglecting to free allocated object td,
causing a memory leak. Fix this by returning via the error return
path that securely kfree's td.

Fixes clang scan-build warning:
security/keys/trusted-keys/trusted_tpm1.c:496:10: warning: Potential
memory leak [unix.Malloc]

Cc: stable@vger.kernel.org
Fixes: 5df16caada3f ("KEYS: trusted: Fix incorrect handling of tpm_get_random()")
Signed-off-by: Colin Ian King 
Reviewed-by: Nick Desaulniers 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen

Merge tag 'queue' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/tpmdd

2021-04-26T15:31:03+00:00

Pull tpm fixes from James Bottomley:
 "Fix a regression in the TPM trusted keys caused by the generic rework
  to add ARM TEE based trusted keys.

  Without this fix, the TPM trusted key subsystem fails to add or load
  any keys"

* tag 'queue' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/tpmdd:
  KEYS: trusted: fix TPM trusted keys for generic framework