kernel/security/integrity/ima/ima_main.c, branch linux-5.1.y

ima: define ima_post_create_tmpfile() hook and add missing call

2019-02-04T22:36:01Z

If tmpfiles can be made persistent, then newly created tmpfiles need to be treated like any other new files in policy. This patch indicates which newly created tmpfiles are in policy, causing the file hash to be calculated on __fput(). Reported-by: Ignaz Forster [rgoldwyn@suse.com: Call ima_post_create_tmpfile() in vfs_tmpfile() as opposed to do_tmpfile(). This will help the case for overlayfs where copy_up is denied while overwriting a file.] Signed-off-by: Goldwyn Rodrigues Signed-off-by: Mimi Zohar

Merge branch 'next-integrity' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security

2019-01-02T17:43:14Z

Pull integrity updates from James Morris: "In Linux 4.19, a new LSM hook named security_kernel_load_data was upstreamed, allowing LSMs and IMA to prevent the kexec_load syscall. Different signature verification methods exist for verifying the kexec'ed kernel image. This adds additional support in IMA to prevent loading unsigned kernel images via the kexec_load syscall, independently of the IMA policy rules, based on the runtime "secure boot" flag. An initial IMA kselftest is included. In addition, this pull request defines a new, separate keyring named ".platform" for storing the preboot/firmware keys needed for verifying the kexec'ed kernel image's signature and includes the associated IMA kexec usage of the ".platform" keyring. (David Howell's and Josh Boyer's patches for reading the preboot/firmware keys, which were previously posted for a different use case scenario, are included here)" * 'next-integrity' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: integrity: Remove references to module keyring ima: Use inode_is_open_for_write ima: Support platform keyring for kernel appraisal efi: Allow the "db" UEFI variable to be suppressed efi: Import certificates from UEFI Secure Boot efi: Add an EFI signature blob parser efi: Add EFI signature data types integrity: Load certs to the platform keyring integrity: Define a trusted platform keyring selftests/ima: kexec_load syscall test ima: don't measure/appraise files on efivarfs x86/ima: retry detecting secure boot mode docs: Extend trusted keys documentation for TPM 2.0 x86/ima: define arch_get_ima_policy() for x86 ima: add support for arch specific policies ima: refactor ima_init_policy() ima: prevent kexec_load syscall based on runtime secureboot flag x86/ima: define arch_ima_get_secureboot integrity: support new struct public_key_signature encoding field

security: integrity: partial revert of make ima_main explicitly non-modular

2018-12-20T17:59:12Z

In commit 4f83d5ea643a ("security: integrity: make ima_main explicitly non-modular") I'd removed after assuming that the function is_module_sig_enforced() was an LSM function and not a core kernel module function. Unfortunately the typical .config selections used in build testing provide an implicit presence, and so normal/typical build testing did not immediately reveal my incorrect assumption. Cc: Mimi Zohar Cc: Dmitry Kasatkin Cc: James Morris Cc: "Serge E. Hallyn" Cc: linux-ima-devel@lists.sourceforge.net Cc: linux-security-module@vger.kernel.org Reported-by: Randy Dunlap Signed-off-by: Paul Gortmaker Signed-off-by: James Morris

Merge branch 'next-integrity' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity into next-integrity

2018-12-17T19:26:46Z

From Mimi: In Linux 4.19, a new LSM hook named security_kernel_load_data was upstreamed, allowing LSMs and IMA to prevent the kexec_load syscall. Different signature verification methods exist for verifying the kexec'ed kernel image. This pull request adds additional support in IMA to prevent loading unsigned kernel images via the kexec_load syscall, independently of the IMA policy rules, based on the runtime "secure boot" flag. An initial IMA kselftest is included. In addition, this pull request defines a new, separate keyring named ".platform" for storing the preboot/firmware keys needed for verifying the kexec'ed kernel image's signature and includes the associated IMA kexec usage of the ".platform" keyring. (David Howell's and Josh Boyer's patches for reading the preboot/firmware keys, which were previously posted for a different use case scenario, are included here.)

ima: Use inode_is_open_for_write

2018-12-13T03:09:34Z

Use the aptly named function rather than open coding the check. No functional changes. Signed-off-by: Nikolay Borisov Signed-off-by: Mimi Zohar

security: integrity: make ima_main explicitly non-modular

2018-12-12T22:58:50Z

The Makefile/Kconfig entry controlling compilation of this code is: obj-$(CONFIG_IMA) += ima.o ima-y := ima_fs.o ima_queue.o ima_init.o ima_main.o ima_crypto.o ima_api.o \ ima_policy.o ima_template.o ima_template_lib.o security/integrity/ima/Kconfig:config IMA security/integrity/ima/Kconfig- bool "Integrity Measurement Architecture(IMA)" ...meaning that it currently is not being built as a module by anyone. Lets remove the couple traces of modular infrastructure use, so that when reading the driver there is no doubt it is builtin-only. We also delete the MODULE_LICENSE tag etc. since all that information is already contained at the top of the file in the comments. Cc: Mimi Zohar Cc: Dmitry Kasatkin Cc: James Morris Cc: "Serge E. Hallyn" Cc: linux-ima-devel@lists.sourceforge.net Cc: linux-security-module@vger.kernel.org Signed-off-by: Paul Gortmaker Signed-off-by: James Morris

ima: prevent kexec_load syscall based on runtime secureboot flag

2018-12-11T12:10:33Z

When CONFIG_KEXEC_VERIFY_SIG is enabled, the kexec_file_load syscall requires the kexec'd kernel image to be signed. Distros are concerned about totally disabling the kexec_load syscall. As a compromise, the kexec_load syscall will only be disabled when CONFIG_KEXEC_VERIFY_SIG is configured and the system is booted with secureboot enabled. This patch disables the kexec_load syscall only for systems booted with secureboot enabled. [zohar@linux.ibm.com: add missing mesage on kexec_load failure] Signed-off-by: Nayna Jain Cc: David Howells Cc: Eric Biederman Cc: Peter Jones Cc: Vivek Goyal Cc: Dave Young Signed-off-by: Mimi Zohar

security/integrity: constify some read-only data

2018-10-10T16:56:15Z

Constify some static data that is never modified, so that it is placed in .rodata. Signed-off-by: Eric Biggers Signed-off-by: Mimi Zohar

Merge branch 'next-general' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security

2018-08-15T17:25:26Z

Pull security subsystem updates from James Morris: - kstrdup() return value fix from Eric Biggers - Add new security_load_data hook to differentiate security checking of kernel-loaded binaries in the case of there being no associated file descriptor, from Mimi Zohar. - Add ability to IMA to specify a policy at build-time, rather than just via command line params or by loading a custom policy, from Mimi. - Allow IMA and LSMs to prevent sysfs firmware load fallback (e.g. if using signed firmware), from Mimi. - Allow IMA to deny loading of kexec kernel images, as they cannot be measured by IMA, from Mimi. * 'next-general' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: security: check for kstrdup() failure in lsm_append() security: export security_kernel_load_data function ima: based on policy warn about loading firmware (pre-allocated buffer) module: replace the existing LSM hook in init_module ima: add build time policy ima: based on policy require signed firmware (sysfs fallback) firmware: add call to LSM hook before firmware sysfs fallback ima: based on policy require signed kexec kernel images kexec: add call to LSM hook in original kexec_load syscall security: define new LSM hook named security_kernel_load_data MAINTAINERS: remove the outdated "LINUX SECURITY MODULE (LSM) FRAMEWORK" entry

ima: based on policy warn about loading firmware (pre-allocated buffer)

2018-07-16T19:31:57Z

Some systems are memory constrained but they need to load very large firmwares. The firmware subsystem allows drivers to request this firmware be loaded from the filesystem, but this requires that the entire firmware be loaded into kernel memory first before it's provided to the driver. This can lead to a situation where we map the firmware twice, once to load the firmware into kernel memory and once to copy the firmware into the final resting place. To resolve this problem, commit a098ecd2fa7d ("firmware: support loading into a pre-allocated buffer") introduced request_firmware_into_buf() API that allows drivers to request firmware be loaded directly into a pre-allocated buffer. Do devices using pre-allocated memory run the risk of the firmware being accessible to the device prior to the completion of IMA's signature verification any more than when using two buffers? (Refer to mailing list discussion[1]). Only on systems with an IOMMU can the access be prevented. As long as the signature verification completes prior to the DMA map is performed, the device can not access the buffer. This implies that the same buffer can not be re-used. Can we ensure the buffer has not been DMA mapped before using the pre-allocated buffer? [1] https://lkml.org/lkml/2018/7/10/56 Signed-off-by: Mimi Zohar Cc: Luis R. Rodriguez Cc: Stephen Boyd Cc: Bjorn Andersson Cc: Ard Biesheuvel Reviewed-by: Kees Cook Signed-off-by: James Morris