user/sven/linux.git/include/linux/ima.h, branch v5.10.90

LSM: Add "contents" flag to kernel_read_file hook

2020-10-05T11:37:03Z

As with the kernel_load_data LSM hook, add a "contents" flag to the kernel_read_file LSM hook that indicates whether the LSM can expect a matching call to the kernel_post_read_file LSM hook with the full contents of the file. With the coming addition of partial file read support for kernel_read_file*() API, the LSM will no longer be able to always see the entire contents of a file during the read calls. For cases where the LSM must read examine the complete file contents, it will need to do so on its own every time the kernel_read_file hook is called with contents=false (or reject such cases). Adjust all existing LSMs to retain existing behavior. Signed-off-by: Kees Cook Reviewed-by: Mimi Zohar Link: https://lore.kernel.org/r/20201002173828.2099543-12-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman

LSM: Introduce kernel_post_load_data() hook

2020-10-05T11:37:03Z

There are a few places in the kernel where LSMs would like to have visibility into the contents of a kernel buffer that has been loaded or read. While security_kernel_post_read_file() (which includes the buffer) exists as a pairing for security_kernel_read_file(), no such hook exists to pair with security_kernel_load_data(). Earlier proposals for just using security_kernel_post_read_file() with a NULL file argument were rejected (i.e. "file" should always be valid for the security_..._file hooks, but it appears at least one case was left in the kernel during earlier refactoring. (This will be fixed in a subsequent patch.) Since not all cases of security_kernel_load_data() can have a single contiguous buffer made available to the LSM hook (e.g. kexec image segments are separately loaded), there needs to be a way for the LSM to reason about its expectations of the hook coverage. In order to handle this, add a "contents" argument to the "kernel_load_data" hook that indicates if the newly added "kernel_post_load_data" hook will be called with the full contents once loaded. That way, LSMs requiring full contents can choose to unilaterally reject "kernel_load_data" with contents=false (which is effectively the existing hook coverage), but when contents=true they can allow it and later evaluate the "kernel_post_load_data" hook once the buffer is loaded. With this change, LSMs can gain coverage over non-file-backed data loads (e.g. init_module(2) and firmware userspace helper), which will happen in subsequent patches. Additionally prepare IMA to start processing these cases. Signed-off-by: Kees Cook Reviewed-by: KP Singh Link: https://lore.kernel.org/r/20201002173828.2099543-9-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman

fs/kernel_read_file: Split into separate include file

2020-10-05T11:34:18Z

Move kernel_read_file* out of linux/fs.h to its own linux/kernel_read_file.h include file. That header gets pulled in just about everywhere and doesn't really need functions not related to the general fs interface. Suggested-by: Christoph Hellwig Signed-off-by: Scott Branden Signed-off-by: Kees Cook Reviewed-by: Christoph Hellwig Reviewed-by: Mimi Zohar Reviewed-by: Luis Chamberlain Acked-by: Greg Kroah-Hartman Acked-by: James Morris Link: https://lore.kernel.org/r/20200706232309.12010-2-scott.branden@broadcom.com Link: https://lore.kernel.org/r/20201002173828.2099543-4-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman

ima: Support additional conditionals in the KEXEC_CMDLINE hook function

2020-07-20T17:28:16Z

Take the properties of the kexec kernel's inode and the current task ownership into consideration when matching a KEXEC_CMDLINE operation to the rules in the IMA policy. This allows for some uniformity when writing IMA policy rules for KEXEC_KERNEL_CHECK, KEXEC_INITRAMFS_CHECK, and KEXEC_CMDLINE operations. Prior to this patch, it was not possible to write a set of rules like this: dont_measure func=KEXEC_KERNEL_CHECK obj_type=foo_t dont_measure func=KEXEC_INITRAMFS_CHECK obj_type=foo_t dont_measure func=KEXEC_CMDLINE obj_type=foo_t measure func=KEXEC_KERNEL_CHECK measure func=KEXEC_INITRAMFS_CHECK measure func=KEXEC_CMDLINE The inode information associated with the kernel being loaded by a kexec_kernel_load(2) syscall can now be included in the decision to measure or not Additonally, the uid, euid, and subj_* conditionals can also now be used in KEXEC_CMDLINE rules. There was no technical reason as to why those conditionals weren't being considered previously other than ima_match_rules() didn't have a valid inode to use so it immediately bailed out for KEXEC_CMDLINE operations rather than going through the full list of conditional comparisons. Signed-off-by: Tyler Hicks Cc: Eric Biederman Cc: kexec@lists.infradead.org Reviewed-by: Lakshmi Ramasubramanian Signed-off-by: Mimi Zohar

ima: verify mprotect change is consistent with mmap policy

2020-05-22T18:41:04Z

Files can be mmap'ed read/write and later changed to execute to circumvent IMA's mmap appraise policy rules. Due to locking issues (mmap semaphore would be taken prior to i_mutex), files can not be measured or appraised at this point. Eliminate this integrity gap, by denying the mprotect PROT_EXECUTE change, if an mmap appraise policy rule exists. On mprotect change success, return 0. On failure, return -EACESS. Reviewed-by: Lakshmi Ramasubramanian Signed-off-by: Mimi Zohar

ima: add a new CONFIG for loading arch-specific policies

2020-03-12T11:43:57Z

Every time a new architecture defines the IMA architecture specific functions - arch_ima_get_secureboot() and arch_ima_get_policy(), the IMA include file needs to be updated. To avoid this "noise", this patch defines a new IMA Kconfig IMA_SECURE_AND_OR_TRUSTED_BOOT option, allowing the different architectures to select it. Suggested-by: Linus Torvalds Signed-off-by: Nayna Jain Acked-by: Ard Biesheuvel Acked-by: Philipp Rudo (s390) Acked-by: Michael Ellerman (powerpc) Signed-off-by: Mimi Zohar

ima: add the ability to query the cached hash of a given file

2020-01-22T20:22:51Z

This allows other parts of the kernel (perhaps a stacked LSM allowing system monitoring, eg. the proposed KRSI LSM [1]) to retrieve the hash of a given file from IMA if it's present in the iint cache. It's true that the existence of the hash means that it's also in the audit logs or in /sys/kernel/security/ima/ascii_runtime_measurements, but it can be difficult to pull that information out for every subsequent exec. This is especially true if a given host has been up for a long time and the file was first measured a long time ago. It should be kept in mind that this function gives access to cached entries which can be removed, for instance on security_inode_free(). This is based on Peter Moody's patch: https://sourceforge.net/p/linux-ima/mailman/message/33036180/ [1] https://lkml.org/lkml/2019/9/10/393 Signed-off-by: Florent Revest Reviewed-by: KP Singh Signed-off-by: Mimi Zohar

IMA: fix measuring asymmetric keys Kconfig

2020-01-09T19:06:06Z

As a result of the asymmetric public keys subtype Kconfig option being defined as tristate, with the existing IMA Makefile, ima_asymmetric_keys.c could be built as a kernel module. To prevent this from happening, this patch defines and uses an intermediate Kconfig boolean option named IMA_MEASURE_ASYMMETRIC_KEYS. Signed-off-by: Lakshmi Ramasubramanian Suggested-by: James.Bottomley Cc: David Howells Cc: Jarkko Sakkinen Reported-by: kbuild test robot # ima_asymmetric_keys.c is built as a kernel module. Fixes: 88e70da170e8 ("IMA: Define an IMA hook to measure keys") Fixes: cb1aa3823c92 ("KEYS: Call the IMA hook to measure keys") [zohar@linux.ibm.com: updated patch description] Signed-off-by: Mimi Zohar

KEYS: Call the IMA hook to measure keys

2019-12-12T13:53:50Z

Call the IMA hook from key_create_or_update() function to measure the payload when a new key is created or an existing key is updated. This patch adds the call to the IMA hook from key_create_or_update() function to measure the key on key create or update. Signed-off-by: Lakshmi Ramasubramanian Cc: David Howells Cc: Jarkko Sakkinen Signed-off-by: Mimi Zohar

powerpc/ima: Add support to initialize ima policy rules

2019-11-12T01:25:49Z

PowerNV systems use a Linux-based bootloader, which rely on the IMA subsystem to enforce different secure boot modes. Since the verification policy may differ based on the secure boot mode of the system, the policies must be defined at runtime. This patch implements arch-specific support to define IMA policy rules based on the runtime secure boot mode of the system. This patch provides arch-specific IMA policies if PPC_SECURE_BOOT config is enabled. Signed-off-by: Nayna Jain Signed-off-by: Mimi Zohar Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1572492694-6520-3-git-send-email-zohar@linux.ibm.com