linux-stable.git/security, branch v5.15.136

KEYS: trusted: Remove redundant static calls usage

2023-10-19T21:05:33+00:00

[ Upstream commit 01bbafc63b65689cb179ca537971286bc27f3b74 ]

Static calls invocations aren't well supported from module __init and
__exit functions. Especially the static call from cleanup_trusted() led
to a crash on x86 kernel with CONFIG_DEBUG_VIRTUAL=y.

However, the usage of static call invocations for trusted_key_init()
and trusted_key_exit() don't add any value from either a performance or
security perspective. Hence switch to use indirect function calls instead.

Note here that although it will fix the current crash report, ultimately
the static call infrastructure should be fixed to either support its
future usage from module __init and __exit functions or not.

Reported-and-tested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Link: https://lore.kernel.org/lkml/ZRhKq6e5nF%2F4ZIV1@fedora/#t
Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
Signed-off-by: Sumit Garg 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

KEYS: trusted: allow use of kernel RNG for key material

2023-10-19T21:05:33+00:00

[ Upstream commit fcd7c26901c83681532c6daac599e53d4df11738 ]

The two existing trusted key sources don't make use of the kernel RNG,
but instead let the hardware doing the sealing/unsealing also
generate the random key material. However, both users and future
backends may want to place less trust into the quality of the trust
source's random number generator and instead reuse the kernel entropy
pool, which can be seeded from multiple entropy sources.

Make this possible by adding a new trusted.rng parameter,
that will force use of the kernel RNG. In its absence, it's up
to the trust source to decide, which random numbers to use,
maintaining the existing behavior.

Suggested-by: Jarkko Sakkinen 
Acked-by: Sumit Garg 
Acked-by: Pankaj Gupta 
Reviewed-by: David Gstir 
Reviewed-by: Pankaj Gupta 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Pankaj Gupta 
Tested-by: Michael Walle  # on ls1028a (non-E and E)
Tested-by: John Ernberg  # iMX8QXP
Signed-off-by: Ahmad Fatoum 
Signed-off-by: Jarkko Sakkinen 
Stable-dep-of: 01bbafc63b65 ("KEYS: trusted: Remove redundant static calls usage")
Signed-off-by: Sasha Levin

ima: rework CONFIG_IMA dependency block

2023-10-10T19:59:07+00:00

[ Upstream commit 91e326563ee34509c35267808a4b1b3ea3db62a8 ]

Changing the direct dependencies of IMA_BLACKLIST_KEYRING and
IMA_LOAD_X509 caused them to no longer depend on IMA, but a
a configuration without IMA results in link failures:

arm-linux-gnueabi-ld: security/integrity/iint.o: in function `integrity_load_keys':
iint.c:(.init.text+0xd8): undefined reference to `ima_load_x509'

aarch64-linux-ld: security/integrity/digsig_asymmetric.o: in function `asymmetric_verify':
digsig_asymmetric.c:(.text+0x104): undefined reference to `ima_blacklist_keyring'

Adding explicit dependencies on IMA would fix this, but a more reliable
way to do this is to enclose the entire Kconfig file in an 'if IMA' block.
This also allows removing the existing direct dependencies.

Fixes: be210c6d3597f ("ima: Finish deprecation of IMA_TRUSTED_KEYRING Kconfig")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Mimi Zohar 
Signed-off-by: Sasha Levin

ima: Finish deprecation of IMA_TRUSTED_KEYRING Kconfig

2023-10-10T19:59:07+00:00

[ Upstream commit be210c6d3597faf330cb9af33b9f1591d7b2a983 ]

The removal of IMA_TRUSTED_KEYRING made IMA_LOAD_X509
and IMA_BLACKLIST_KEYRING unavailable because the latter
two depend on the former. Since IMA_TRUSTED_KEYRING was
deprecated in favor of INTEGRITY_TRUSTED_KEYRING use it
as a dependency for the two Kconfigs affected by the
deprecation.

Fixes: 5087fd9e80e5 ("ima: Remove deprecated IMA_TRUSTED_KEYRING Kconfig")
Signed-off-by: Oleksandr Tymoshenko 
Reviewed-by: Nayna Jain 
Signed-off-by: Mimi Zohar 
Signed-off-by: Sasha Levin

Smack:- Use overlay inode label in smack_inode_copy_up()

2023-10-06T11:18:20+00:00

[ Upstream commit 387ef964460f14fe1c1ea29aba70e22731ea7cf7 ]

Currently in "smack_inode_copy_up()" function, process label is
changed with the label on parent inode. Due to which,
process is assigned directory label and whatever file or directory
created by the process are also getting directory label
which is wrong label.

Changes has been done to use label of overlay inode instead
of parent inode.

Signed-off-by: Vishal Goel 
Signed-off-by: Casey Schaufler 
Signed-off-by: Sasha Levin

smack: Retrieve transmuting information in smack_inode_getsecurity()

2023-10-06T11:18:20+00:00

[ Upstream commit 3a3d8fce31a49363cc31880dce5e3b0617c9c38b ]

Enhance smack_inode_getsecurity() to retrieve the value for
SMACK64TRANSMUTE from the inode security blob, similarly to SMACK64.

This helps to display accurate values in the situation where the security
labels come from mount options and not from xattrs.

Signed-off-by: Roberto Sassu 
Signed-off-by: Casey Schaufler 
Signed-off-by: Sasha Levin

smack: Record transmuting in smk_transmuted

2023-10-06T11:18:20+00:00

[ Upstream commit 2c085f3a8f23c9b444e8b99d93c15d7ce870fc4e ]

smack_dentry_create_files_as() determines whether transmuting should occur
based on the label of the parent directory the new inode will be added to,
and not the label of the directory where it is created.

This helps for example to do transmuting on overlayfs, since the latter
first creates the inode in the working directory, and then moves it to the
correct destination.

However, despite smack_dentry_create_files_as() provides the correct label,
smack_inode_init_security() does not know from passed information whether
or not transmuting occurred. Without this information,
smack_inode_init_security() cannot set SMK_INODE_CHANGED in smk_flags,
which will result in the SMACK64TRANSMUTE xattr not being set in
smack_d_instantiate().

Thus, add the smk_transmuted field to the task_smack structure, and set it
in smack_dentry_create_files_as() to smk_task if transmuting occurred. If
smk_task is equal to smk_transmuted in smack_inode_init_security(), act as
if transmuting was successful but without taking the label from the parent
directory (the inode label was already set correctly from the current
credentials in smack_inode_alloc_security()).

Signed-off-by: Roberto Sassu 
Signed-off-by: Casey Schaufler 
Signed-off-by: Sasha Levin

smackfs: Prevent underflow in smk_set_cipso()

2023-09-19T10:22:39+00:00

[ Upstream commit 3ad49d37cf5759c3b8b68d02e3563f633d9c1aee ]

There is a upper bound to "catlen" but no lower bound to prevent
negatives.  I don't see that this necessarily causes a problem but we
may as well be safe.

Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel")
Signed-off-by: Dan Carpenter 
Signed-off-by: Casey Schaufler 
Signed-off-by: Sasha Levin

ima: Remove deprecated IMA_TRUSTED_KEYRING Kconfig

2023-09-19T10:22:38+00:00

[ Upstream commit 5087fd9e80e539d2163accd045b73da64de7de95 ]

Time to remove "IMA_TRUSTED_KEYRING".

Fixes: f4dc37785e9b ("integrity: define '.evm' as a builtin 'trusted' keyring") # v4.5+
Signed-off-by: Nayna Jain 
Signed-off-by: Mimi Zohar 
Signed-off-by: Sasha Levin

of: kexec: Mark ima_{free,stable}_kexec_buffer() as __init

2023-09-19T10:22:30+00:00

This commit has no direct upstream equivalent.

After commit d48016d74836 ("mm,ima,kexec,of: use memblock_free_late from
ima_free_kexec_buffer") in 5.15, there is a modpost warning for certain
configurations:

  WARNING: modpost: vmlinux.o(.text+0xb14064): Section mismatch in reference from the function ima_free_kexec_buffer() to the function .init.text:__memblock_free_late()
  The function ima_free_kexec_buffer() references
  the function __init __memblock_free_late().
  This is often because ima_free_kexec_buffer lacks a __init
  annotation or the annotation of __memblock_free_late is wrong.

In mainline, there is no issue because ima_free_kexec_buffer() is marked
as __init, which was done as part of commit b69a2afd5afc ("x86/kexec:
Carry forward IMA measurement log on kexec") in 6.0, which is not
suitable for stable.

Mark ima_free_kexec_buffer() and its single caller
ima_load_kexec_buffer() as __init in 5.15, as ima_load_kexec_buffer() is
only called from ima_init(), which is __init, clearing up the warning.

Signed-off-by: Nathan Chancellor 
Acked-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman