summaryrefslogtreecommitdiff
path: root/security/integrity/ima
AgeCommit message (Collapse)AuthorFilesLines
10 daysima: Handle error code returned by ima_filter_rule_match()Zhao Yipeng1-1/+1
[ Upstream commit 738c9738e690f5cea24a3ad6fd2d9a323cf614f6 ] In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match. Fixes: 4af4662fa4a9d ("integrity: IMA policy") Signed-off-by: Zhao Yipeng <zhaoyipeng5@huawei.com> Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-11-24ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattrCoiby Xu1-5/+18
[ Upstream commit 88b4cbcf6b041ae0f2fc8a34554a5b6a83a2b7cd ] Currently when both IMA and EVM are in fix mode, the IMA signature will be reset to IMA hash if a program first stores IMA signature in security.ima and then writes/removes some other security xattr for the file. For example, on Fedora, after booting the kernel with "ima_appraise=fix evm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima, installing/reinstalling a package will not make good reference IMA signature generated. Instead IMA hash is generated, # getfattr -m - -d -e hex /usr/bin/bash # file: usr/bin/bash security.ima=0x0404... This happens because when setting security.selinux, the IMA_DIGSIG flag that had been set early was cleared. As a result, IMA hash is generated when the file is closed. Similarly, IMA signature can be cleared on file close after removing security xattr like security.evm or setting/removing ACL. Prevent replacing the IMA file signature with a file hash, by preventing the IMA_DIGSIG flag from being reset. Here's a minimal C reproducer which sets security.selinux as the last step which can also replaced by removing security.evm or setting ACL, #include <stdio.h> #include <sys/xattr.h> #include <fcntl.h> #include <unistd.h> #include <string.h> #include <stdlib.h> int main() { const char* file_path = "/usr/sbin/test_binary"; const char* hex_string = "030204d33204490066306402304"; int length = strlen(hex_string); char* ima_attr_value; int fd; fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644); if (fd == -1) { perror("Error opening file"); return 1; } ima_attr_value = (char*)malloc(length / 2 ); for (int i = 0, j = 0; i < length; i += 2, j++) { sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]); } if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } const char* selinux_value= "system_u:object_r:bin_t:s0"; if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } close(fd); return 0; } Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-09-19ima: limit the number of ToMToU integrity violationsMimi Zohar1-5/+11
[ Upstream commit a414016218ca97140171aa3bb926b02e1f68c2cc ] Each time a file in policy, that is already opened for read, is opened for write, a Time-of-Measure-Time-of-Use (ToMToU) integrity violation audit message is emitted and a violation record is added to the IMA measurement list. This occurs even if a ToMToU violation has already been recorded. Limit the number of ToMToU integrity violations per file open for read. Note: The IMA_MAY_EMIT_TOMTOU atomic flag must be set from the reader side based on policy. This may result in a per file open for read ToMToU violation. Since IMA_MUST_MEASURE is only used for violations, rename the atomic IMA_MUST_MEASURE flag to IMA_MAY_EMIT_TOMTOU. Cc: stable@vger.kernel.org # applies cleanly up to linux-6.6 Tested-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Petr Vorel <pvorel@suse.cz> Tested-by: Petr Vorel <pvorel@suse.cz> Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> [ adapted IMA flag definitions location from ima.h to integrity.h ] Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-04ima: process_measurement() needlessly takes inode_lock() on MAY_READFrederick Lawler1-1/+3
[ Upstream commit 30d68cb0c37ebe2dc63aa1d46a28b9163e61caa2 ] On IMA policy update, if a measure rule exists in the policy, IMA_MEASURE is set for ima_policy_flags which makes the violation_check variable always true. Coupled with a no-action on MAY_READ for a FILE_CHECK call, we're always taking the inode_lock(). This becomes a performance problem for extremely heavy read-only workloads. Therefore, prevent this only in the case there's no action to be taken. Signed-off-by: Frederick Lawler <fred@cloudflare.com> Acked-by: Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13ima: Reset IMA_NONACTION_RULE_FLAGS after post_setattrRoberto Sassu1-2/+5
commit 57a0ef02fefafc4b9603e33a18b669ba5ce59ba3 upstream. Commit 0d73a55208e9 ("ima: re-introduce own integrity cache lock") mistakenly reverted the performance improvement introduced in commit 42a4c603198f0 ("ima: fix ima_inode_post_setattr"). The unused bit mask was subsequently removed by commit 11c60f23ed13 ("integrity: Remove unused macro IMA_ACTION_RULE_FLAGS"). Restore the performance improvement by introducing the new mask IMA_NONACTION_RULE_FLAGS, equal to IMA_NONACTION_FLAGS without IMA_NEW_FILE, which is not a rule-specific flag. Finally, reset IMA_NONACTION_RULE_FLAGS instead of IMA_NONACTION_FLAGS in process_measurement(), if the IMA_CHANGE_ATTR atomic flag is set (after file metadata modification). With this patch, new files for which metadata were modified while they are still open, can be reopened before the last file close (when security.ima is written), since the IMA_NEW_FILE flag is not cleared anymore. Otherwise, appraisal fails because security.ima is missing (files with IMA_NEW_FILE set are an exception). Cc: stable@vger.kernel.org # v4.16.x Fixes: 0d73a55208e9 ("ima: re-introduce own integrity cache lock") Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-22ima: fix buffer overrun in ima_eventdigest_init_commonSamasth Norway Ananda1-4/+10
commit 923168a0631bc42fffd55087b337b1b6c54dcff5 upstream. Function ima_eventdigest_init() calls ima_eventdigest_init_common() with HASH_ALGO__LAST which is then used to access the array hash_digest_size[] leading to buffer overrun. Have a conditional statement to handle this. Fixes: 9fab303a2cb3 ("ima: fix violation measurement list record") Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com> Tested-by: Enrico Bravi (PhD at polito.it) <enrico.bravi@huawei.com> Cc: stable@vger.kernel.org # 5.19+ Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-11ima: Avoid blocking in RCU read-side critical sectionGUO Zihua2-7/+10
commit 9a95c5bfbf02a0a7f5983280fe284a0ff0836c34 upstream. A panic happens in ima_match_policy: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 PGD 42f873067 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 5 PID: 1286325 Comm: kubeletmonit.sh Kdump: loaded Tainted: P Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:ima_match_policy+0x84/0x450 Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39 7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d f2 b9 f4 00 0f 84 9c 01 00 00 <44> 85 73 10 74 ea 44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f RSP: 0018:ff71570009e07a80 EFLAGS: 00010207 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200 RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739 R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970 R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001 FS: 00007f5195b51740(0000) GS:ff3e278b12d40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ima_get_action+0x22/0x30 process_measurement+0xb0/0x830 ? page_add_file_rmap+0x15/0x170 ? alloc_set_pte+0x269/0x4c0 ? prep_new_page+0x81/0x140 ? simple_xattr_get+0x75/0xa0 ? selinux_file_open+0x9d/0xf0 ima_file_check+0x64/0x90 path_openat+0x571/0x1720 do_filp_open+0x9b/0x110 ? page_counter_try_charge+0x57/0xc0 ? files_cgroup_alloc_fd+0x38/0x60 ? __alloc_fd+0xd4/0x250 ? do_sys_open+0x1bd/0x250 do_sys_open+0x1bd/0x250 do_syscall_64+0x5d/0x1d0 entry_SYSCALL_64_after_hwframe+0x65/0xca Commit c7423dbdbc9e ("ima: Handle -ESTALE returned by ima_filter_rule_match()") introduced call to ima_lsm_copy_rule within a RCU read-side critical section which contains kmalloc with GFP_KERNEL. This implies a possible sleep and violates limitations of RCU read-side critical sections on non-PREEMPT systems. Sleeping within RCU read-side critical section might cause synchronize_rcu() returning early and break RCU protection, allowing a UAF to happen. The root cause of this issue could be described as follows: | Thread A | Thread B | | |ima_match_policy | | | rcu_read_lock | |ima_lsm_update_rule | | | synchronize_rcu | | | | kmalloc(GFP_KERNEL)| | | sleep | ==> synchronize_rcu returns early | kfree(entry) | | | | entry = entry->next| ==> UAF happens and entry now becomes NULL (or could be anything). | | entry->action | ==> Accessing entry might cause panic. To fix this issue, we are converting all kmalloc that is called within RCU read-side critical section to use GFP_ATOMIC. Fixes: c7423dbdbc9e ("ima: Handle -ESTALE returned by ima_filter_rule_match()") Cc: stable@vger.kernel.org Signed-off-by: GUO Zihua <guozihua@huawei.com> Acked-by: John Johansen <john.johansen@canonical.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com> [PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case] Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-21ima: Fix use-after-free on a dentry's dname.nameStefan Berger2-7/+26
commit be84f32bb2c981ca670922e047cdde1488b233de upstream. ->d_name.name can change on rename and the earlier value can be freed; there are conditions sufficient to stabilize it (->d_lock on dentry, ->d_lock on its parent, ->i_rwsem exclusive on the parent's inode, rename_lock), but none of those are met at any of the sites. Take a stable snapshot of the name instead. Link: https://lore.kernel.org/all/20240202182732.GE2087318@ZenIV/ Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-28ima: detect changes to the backing overlay fileMimi Zohar2-1/+20
commit b836c4d29f2744200b2af41e14bf50758dddc818 upstream. Commit 18b44bc5a672 ("ovl: Always reevaluate the file signature for IMA") forced signature re-evaulation on every file access. Instead of always re-evaluating the file's integrity, detect a change to the backing file, by comparing the cached file metadata with the backing file's metadata. Verifying just the i_version has not changed is insufficient. In addition save and compare the i_ino and s_dev as well. Reviewed-by: Amir Goldstein <amir73il@gmail.com> Tested-by: Eric Snowberg <eric.snowberg@oracle.com> Tested-by: Raul E Rangel <rrangel@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-27ima: rework CONFIG_IMA dependency blockArnd Bergmann1-12/+6
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 <arnd@arndb.de> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2023-09-27ima: Finish deprecation of IMA_TRUSTED_KEYRING KconfigOleksandr Tymoshenko1-2/+2
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 <ovt@google.com> Reviewed-by: Nayna Jain <nayna@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2023-08-30Merge tag 'integrity-v6.6' of ↵Linus Torvalds5-30/+16
git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity Pull integrity subsystem updates from Mimi Zohar: - With commit 099f26f22f58 ("integrity: machine keyring CA configuration") certificates may be loaded onto the IMA keyring, directly or indirectly signed by keys on either the "builtin" or the "machine" keyrings. With the ability for the system/machine owner to sign the IMA policy itself without needing to recompile the kernel, update the IMA architecture specific policy rules to require the IMA policy itself be signed. [ As commit 099f26f22f58 was upstreamed in linux-6.4, updating the IMA architecture specific policy now to require signed IMA policies may break userspace expectations. ] - IMA only checked the file data hash was not on the system blacklist keyring for files with an appended signature (e.g. kernel modules, Power kernel image). Check all file data hashes regardless of how it was signed - Code cleanup, and a kernel-doc update * tag 'integrity-v6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity: kexec_lock: Replace kexec_mutex() by kexec_lock() in two comments ima: require signed IMA policy when UEFI secure boot is enabled integrity: Always reference the blacklist keyring with appraisal ima: Remove deprecated IMA_TRUSTED_KEYRING Kconfig
2023-08-29Merge tag 'tpmdd-v6.6' of ↵Linus Torvalds1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd Pull tpm updates from Jarkko Sakkinen: - Restrict linking of keys to .ima and .evm keyrings based on digitalSignature attribute in the certificate - PowerVM: load machine owner keys into the .machine [1] keyring - PowerVM: load module signing keys into the secondary trusted keyring (keys blessed by the vendor) - tpm_tis_spi: half-duplex transfer mode - tpm_tis: retry corrupted transfers - Apply revocation list (.mokx) to an all system keyrings (e.g. .machine keyring) Link: https://blogs.oracle.com/linux/post/the-machine-keyring [1] * tag 'tpmdd-v6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: certs: Reference revocation list for all keyrings tpm/tpm_tis_synquacer: Use module_platform_driver macro to simplify the code tpm: remove redundant variable len tpm_tis: Resend command to recover from data transfer errors tpm_tis: Use responseRetry to recover from data transfer errors tpm_tis: Move CRC check to generic send routine tpm_tis_spi: Add hardware wait polling KEYS: Replace all non-returning strlcpy with strscpy integrity: PowerVM support for loading third party code signing keys integrity: PowerVM machine keyring enablement integrity: check whether imputed trust is enabled integrity: remove global variable from machine_keyring.c integrity: ignore keys failing CA restrictions on non-UEFI platform integrity: PowerVM support for loading CA keys on machine keyring integrity: Enforce digitalSignature usage in the ima and evm keyrings KEYS: DigitalSignature link restriction tpm_tis: Revert "tpm_tis: Disable interrupts on ThinkPad T490s"
2023-08-18integrity: Annotate struct ima_rule_opt_list with __counted_byKees Cook1-2/+2
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct ima_rule_opt_list. Additionally, since the element count member must be set before accessing the annotated flexible array member, move its initialization earlier. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Mimi Zohar <zohar@linux.ibm.com> Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com> Cc: Paul Moore <paul@paul-moore.com> Cc: James Morris <jmorris@namei.org> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: linux-integrity@vger.kernel.org Cc: linux-security-module@vger.kernel.org Acked-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Link: https://lore.kernel.org/r/20230817210327.never.598-kees@kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
2023-08-17integrity: Enforce digitalSignature usage in the ima and evm keyringsEric Snowberg1-1/+2
After being vouched for by a system keyring, only allow keys into the .ima and .evm keyrings that have the digitalSignature usage field set. Link: https://lore.kernel.org/all/41dffdaeb7eb7840f7e38bc691fbda836635c9f9.camel@linux.ibm.com Suggested-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> Acked-and-tested-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-08-07kexec_lock: Replace kexec_mutex() by kexec_lock() in two commentsWenyu Liu1-1/+1
kexec_mutex is replaced by an atomic variable in 05c6257433b (panic, kexec: make __crash_kexec() NMI safe). But there are still two comments that referenced kexec_mutex, replace them by kexec_lock. Signed-off-by: Wenyu Liu <liuwenyu7@huawei.com> Acked-by: Baoquan He <bhe@redhat.com> Acked-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2023-08-01ima: require signed IMA policy when UEFI secure boot is enabledCoiby Xu1-0/+3
With commit 099f26f22f58 ("integrity: machine keyring CA configuration"), users are able to add custom IMA CA keys via MOK. This allows users to sign their own IMA polices without recompiling the kernel. For the sake of security, mandate signed IMA policy when UEFI secure boot is enabled. Note this change may affect existing users/tests i.e users won't be able to load an unsigned IMA policy when the IMA architecture specific policy is configured and UEFI secure boot is enabled. Suggested-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2023-08-01integrity: Always reference the blacklist keyring with appraisalEric Snowberg2-17/+12
Commit 273df864cf746 ("ima: Check against blacklisted hashes for files with modsig") introduced an appraise_flag option for referencing the blacklist keyring. Any matching binary found on this keyring fails signature validation. This flag only works with module appended signatures. An important part of a PKI infrastructure is to have the ability to do revocation at a later time should a vulnerability be found. Expand the revocation flag usage to all appraisal functions. The flag is now enabled by default. Setting the flag with an IMA policy has been deprecated. Without a revocation capability like this in place, only authenticity can be maintained. With this change, integrity can now be achieved with digital signature based IMA appraisal. Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> Reviewed-by: Nayna Jain <nayna@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2023-08-01ima: Remove deprecated IMA_TRUSTED_KEYRING KconfigNayna Jain1-12/+0
Time to remove "IMA_TRUSTED_KEYRING". Fixes: f4dc37785e9b ("integrity: define '.evm' as a builtin 'trusted' keyring") # v4.5+ Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2023-06-28Merge tag 'integrity-v6.5' of ↵Linus Torvalds4-8/+19
git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity Pull integrity subsystem updates from Mimi Zohar: "An i_version change, one bug fix, and three kernel doc fixes: - instead of IMA detecting file change by directly accesssing i_version, it now calls vfs_getattr_nosec(). - fix a race condition when inserting a new node in the iint rb-tree" * tag 'integrity-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity: ima: Fix build warnings evm: Fix build warnings evm: Complete description of evm_inode_setattr() integrity: Fix possible multiple allocation in integrity_inode_get() IMA: use vfs_getattr_nosec to get the i_version
2023-06-14fsverity: rework fsverity_get_digest() againEric Biggers1-19/+12
Address several issues with the calling convention and documentation of fsverity_get_digest(): - Make it provide the hash algorithm as either a FS_VERITY_HASH_ALG_* value or HASH_ALGO_* value, at the caller's choice, rather than only a HASH_ALGO_* value as it did before. This allows callers to work with the fsverity native algorithm numbers if they want to. HASH_ALGO_* is what IMA uses, but other users (e.g. overlayfs) should use FS_VERITY_HASH_ALG_* to match fsverity-utils and the fsverity UAPI. - Make it return the digest size so that it doesn't need to be looked up separately. Use the return value for this, since 0 works nicely for the "file doesn't have fsverity enabled" case. This also makes it clear that no other errors are possible. - Rename the 'digest' parameter to 'raw_digest' and clearly document that it is only useful in combination with the algorithm ID. This hopefully clears up a point of confusion. - Export it to modules, since overlayfs will need it for checking the fsverity digests of lowerdata files (https://lore.kernel.org/r/dd294a44e8f401e6b5140029d8355f88748cd8fd.1686565330.git.alexl@redhat.com). Acked-by: Mimi Zohar <zohar@linux.ibm.com> # for the IMA piece Link: https://lore.kernel.org/r/20230612190047.59755-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com>
2023-06-06ima: Fix build warningsRoberto Sassu2-1/+5
Fix build warnings (function parameters description) for ima_collect_modsig(), ima_match_policy() and ima_parse_add_rule(). Fixes: 15588227e086 ("ima: Collect modsig") # v5.4+ Fixes: 2fe5d6def167 ("ima: integrity appraisal extension") # v5.14+ Fixes: 4af4662fa4a9 ("integrity: IMA policy") # v3.2+ Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2023-05-24IMA: use vfs_getattr_nosec to get the i_versionJeff Layton2-7/+14
IMA currently accesses the i_version out of the inode directly when it does a measurement. This is fine for most simple filesystems, but can be problematic with more complex setups (e.g. overlayfs). Make IMA instead call vfs_getattr_nosec to get this info. This allows the filesystem to determine whether and how to report the i_version, and should allow IMA to work properly with a broader class of filesystems in the future. Reported-and-Tested-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2023-04-29Merge tag 'integrity-v6.4' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity Pull integrity update from Mimi Zohar: "Just one one bug fix. Other integrity changes are being upstreamed via the tpm and lsm trees" * tag 'integrity-v6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity: IMA: allow/fix UML builds
2023-04-06mm, treewide: redefine MAX_ORDER sanelyKirill A. Shutemov1-1/+1
MAX_ORDER currently defined as number of orders page allocator supports: user can ask buddy allocator for page order between 0 and MAX_ORDER-1. This definition is counter-intuitive and lead to number of bugs all over the kernel. Change the definition of MAX_ORDER to be inclusive: the range of orders user can ask from buddy allocator is 0..MAX_ORDER now. [kirill@shutemov.name: fix min() warning] Link: https://lkml.kernel.org/r/20230315153800.32wib3n5rickolvh@box [akpm@linux-foundation.org: fix another min_t warning] [kirill@shutemov.name: fixups per Zi Yan] Link: https://lkml.kernel.org/r/20230316232144.b7ic4cif4kjiabws@box.shutemov.name [akpm@linux-foundation.org: fix underlining in docs] Link: https://lore.kernel.org/oe-kbuild-all/202303191025.VRCTk6mP-lkp@intel.com/ Link: https://lkml.kernel.org/r/20230315113133.11326-11-kirill.shutemov@linux.intel.com Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: Michael Ellerman <mpe@ellerman.id.au> [powerpc] Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-03-16IMA: allow/fix UML buildsRandy Dunlap1-1/+1
UML supports HAS_IOMEM since 0bbadafdc49d (um: allow disabling NO_IOMEM). Current IMA build on UML fails on allmodconfig (with TCG_TPM=m): ld: security/integrity/ima/ima_queue.o: in function `ima_add_template_entry': ima_queue.c:(.text+0x2d9): undefined reference to `tpm_pcr_extend' ld: security/integrity/ima/ima_init.o: in function `ima_init': ima_init.c:(.init.text+0x43f): undefined reference to `tpm_default_chip' ld: security/integrity/ima/ima_crypto.o: in function `ima_calc_boot_aggregate_tfm': ima_crypto.c:(.text+0x1044): undefined reference to `tpm_pcr_read' ld: ima_crypto.c:(.text+0x10d8): undefined reference to `tpm_pcr_read' Modify the IMA Kconfig entry so that it selects TCG_TPM if HAS_IOMEM is set, regardless of the UML Kconfig setting. This updates TCG_TPM from =m to =y and fixes the linker errors. Fixes: f4a0391dfa91 ("ima: fix Kconfig dependencies") Cc: Stable <stable@vger.kernel.org> # v5.14+ Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: Richard Weinberger <richard@nod.at> Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: linux-um@lists.infradead.org Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2023-02-22Merge tag 'integrity-v6.3' of ↵Linus Torvalds5-12/+42
git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity Pull integrity update from Mimi Zohar: "One doc and one code cleanup, and two bug fixes" * tag 'integrity-v6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity: ima: Introduce MMAP_CHECK_REQPROT hook ima: Align ima_file_mmap() parameters with mmap_file LSM hook evm: call dump_security_xattr() in all cases to remove code duplication ima: fix ima_delete_rules() kernel-doc warning ima: return IMA digest value only when IMA_COLLECTED flag is set ima: fix error handling logic when file measurement failed
2023-01-31ima: Introduce MMAP_CHECK_REQPROT hookRoberto Sassu5-6/+32
Commit 98de59bfe4b2f ("take calculation of final prot in security_mmap_file() into a helper") caused ima_file_mmap() to receive the protections requested by the application and not those applied by the kernel. After restoring the original MMAP_CHECK behavior, existing attestation servers might be broken due to not being ready to handle new entries (previously missing) in the IMA measurement list. Restore the original correct MMAP_CHECK behavior, instead of keeping the current buggy one and introducing a new hook with the correct behavior. Otherwise, there would have been the risk of IMA users not noticing the problem at all, as they would actively have to update the IMA policy, to switch to the correct behavior. Also, introduce the new MMAP_CHECK_REQPROT hook to keep the current behavior, so that IMA users could easily fix a broken attestation server, although this approach is discouraged due to potentially missing measurements. Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2023-01-31ima: Align ima_file_mmap() parameters with mmap_file LSM hookRoberto Sassu1-2/+5
Commit 98de59bfe4b2f ("take calculation of final prot in security_mmap_file() into a helper") moved the code to update prot, to be the actual protections applied to the kernel, to a new helper called mmap_prot(). However, while without the helper ima_file_mmap() was getting the updated prot, with the helper ima_file_mmap() gets the original prot, which contains the protections requested by the application. A possible consequence of this change is that, if an application calls mmap() with only PROT_READ, and the kernel applies PROT_EXEC in addition, that application would have access to executable memory without having this event recorded in the IMA measurement list. This situation would occur for example if the application, before mmap(), calls the personality() system call with READ_IMPLIES_EXEC as the first argument. Align ima_file_mmap() parameters with those of the mmap_file LSM hook, so that IMA can receive both the requested prot and the final prot. Since the requested protections are stored in a new variable, and the final protections are stored in the existing variable, this effectively restores the original behavior of the MMAP_CHECK hook. Cc: stable@vger.kernel.org Fixes: 98de59bfe4b2 ("take calculation of final prot in security_mmap_file() into a helper") Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2023-01-19fs: port i_{g,u}id_into_vfs{g,u}id() to mnt_idmapChristian Brauner1-3/+2
Convert to struct mnt_idmap. Remove legacy file_mnt_user_ns() and mnt_user_ns(). Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conversion to struct mnt_idmap. Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevent on the mount level. Especially for non-vfs developers without detailed knowledge in this area this can be a potential source for bugs. Once the conversion to struct mnt_idmap is done all helpers down to the really low-level helpers will take a struct mnt_idmap argument instead of two namespace arguments. This way it becomes impossible to conflate the two eliminating the possibility of any bugs. All of the vfs and all filesystems only operate on struct mnt_idmap. Acked-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
2023-01-19fs: port acl to mnt_idmapChristian Brauner1-1/+1
Convert to struct mnt_idmap. Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conversion to struct mnt_idmap. Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevent on the mount level. Especially for non-vfs developers without detailed knowledge in this area this can be a potential source for bugs. Once the conversion to struct mnt_idmap is done all helpers down to the really low-level helpers will take a struct mnt_idmap argument instead of two namespace arguments. This way it becomes impossible to conflate the two eliminating the possibility of any bugs. All of the vfs and all filesystems only operate on struct mnt_idmap. Acked-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
2023-01-19fs: port xattr to mnt_idmapChristian Brauner7-35/+36
Convert to struct mnt_idmap. Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conversion to struct mnt_idmap. Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevent on the mount level. Especially for non-vfs developers without detailed knowledge in this area this can be a potential source for bugs. Once the conversion to struct mnt_idmap is done all helpers down to the really low-level helpers will take a struct mnt_idmap argument instead of two namespace arguments. This way it becomes impossible to conflate the two eliminating the possibility of any bugs. All of the vfs and all filesystems only operate on struct mnt_idmap. Acked-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
2023-01-19fs: port ->permission() to pass mnt_idmapChristian Brauner2-2/+2
Convert to struct mnt_idmap. Last cycle we merged the necessary infrastructure in 256c8aed2b42 ("fs: introduce dedicated idmap type for mounts"). This is just the conversion to struct mnt_idmap. Currently we still pass around the plain namespace that was attached to a mount. This is in general pretty convenient but it makes it easy to conflate namespaces that are relevant on the filesystem with namespaces that are relevent on the mount level. Especially for non-vfs developers without detailed knowledge in this area this can be a potential source for bugs. Once the conversion to struct mnt_idmap is done all helpers down to the really low-level helpers will take a struct mnt_idmap argument instead of two namespace arguments. This way it becomes impossible to conflate the two eliminating the possibility of any bugs. All of the vfs and all filesystems only operate on struct mnt_idmap. Acked-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
2023-01-18ima: fix ima_delete_rules() kernel-doc warningRandy Dunlap1-1/+2
Use correct kernel-doc syntax in the function description to prevent a kernel-doc warning: security/integrity/ima/ima_policy.c:1964: warning: expecting prototype for ima_delete_rules() called to cleanup invalid in(). Prototype was for ima_delete_rules() instead Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2023-01-18ima: return IMA digest value only when IMA_COLLECTED flag is setMatt Bobrowski1-1/+1
The IMA_COLLECTED flag indicates whether the IMA subsystem has successfully collected a measurement for a given file object. Ensure that we return the respective digest value stored within the iint entry only when this flag has been set. Failing to check for the presence of this flag exposes consumers of this IMA API to receive potentially undesired IMA digest values when an erroneous condition has been experienced in some of the lower level IMA API code. Signed-off-by: Matt Bobrowski <mattbobrowski@google.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2023-01-18ima: fix error handling logic when file measurement failedMatt Bobrowski2-2/+2
Restore the error handling logic so that when file measurement fails, the respective iint entry is not left with the digest data being populated with zeroes. Fixes: 54f03916fb89 ("ima: permit fsverity's file digests in the IMA measurement list") Cc: stable@vger.kernel.org # 5.19 Signed-off-by: Matt Bobrowski <mattbobrowski@google.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2022-12-21Merge tag 'fs.vfsuid.ima.v6.2-rc1' of ↵Linus Torvalds1-0/+24
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping Pull vfsuid cleanup from Christian Brauner: "This moves the ima specific vfs{g,u}id_t comparison helpers out of the header and into the one file in ima where they are used. We shouldn't incentivize people to use them by placing them into the header. As discussed and suggested by Linus in [1] let's just define them locally in the one file in ima where they are used" Link: https://lore.kernel.org/lkml/CAHk-=wj4BpEwUd=OkTv1F9uykvSrsBNZJVHMp+p_+e2kiV71_A@mail.gmail.com [1] * tag 'fs.vfsuid.ima.v6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping: mnt_idmapping: move ima-only helpers to ima
2022-12-14Merge tag 'integrity-v6.2' of ↵Linus Torvalds4-21/+48
git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity Pull integrity updates from Mimi Zohar: "Aside from the one cleanup, the other changes are bug fixes: Cleanup: - Include missing iMac Pro 2017 in list of Macs with T2 security chip Bug fixes: - Improper instantiation of "encrypted" keys with user provided data - Not handling delay in updating LSM label based IMA policy rules (-ESTALE) - IMA and integrity memory leaks on error paths - CONFIG_IMA_DEFAULT_HASH_SM3 hash algorithm renamed" * tag 'integrity-v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity: ima: Fix hash dependency to correct algorithm ima: Fix misuse of dereference of pointer in template_desc_init_fields() integrity: Fix memory leakage in keyring allocation error path ima: Fix memory leak in __ima_inode_hash() ima: Handle -ESTALE returned by ima_filter_rule_match() ima: Simplify ima_lsm_copy_rule ima: Fix a potential NULL pointer access in ima_restore_measurement_list efi: Add iMac Pro 2017 to uefi skip cert quirk KEYS: encrypted: fix key instantiation with user-provided data
2022-12-13Merge tag 'lsm-pr-20221212' of ↵Linus Torvalds4-13/+15
git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm Pull lsm updates from Paul Moore: - Improve the error handling in the device cgroup such that memory allocation failures when updating the access policy do not potentially alter the policy. - Some minor fixes to reiserfs to ensure that it properly releases LSM-related xattr values. - Update the security_socket_getpeersec_stream() LSM hook to take sockptr_t values. Previously the net/BPF folks updated the getsockopt code in the network stack to leverage the sockptr_t type to make it easier to pass both kernel and __user pointers, but unfortunately when they did so they didn't convert the LSM hook. While there was/is no immediate risk by not converting the LSM hook, it seems like this is a mistake waiting to happen so this patch proactively does the LSM hook conversion. - Convert vfs_getxattr_alloc() to return an int instead of a ssize_t and cleanup the callers. Internally the function was never going to return anything larger than an int and the callers were doing some very odd things casting the return value; this patch fixes all that and helps bring a bit of sanity to vfs_getxattr_alloc() and its callers. - More verbose, and helpful, LSM debug output when the system is booted with "lsm.debug" on the command line. There are examples in the commit description, but the quick summary is that this patch provides better information about which LSMs are enabled and the ordering in which they are processed. - General comment and kernel-doc fixes and cleanups. * tag 'lsm-pr-20221212' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm: lsm: Fix description of fs_context_parse_param lsm: Add/fix return values in lsm_hooks.h and fix formatting lsm: Clarify documentation of vm_enough_memory hook reiserfs: Add missing calls to reiserfs_security_free() lsm,fs: fix vfs_getxattr_alloc() return type and caller error paths device_cgroup: Roll back to original exceptions after copy failure LSM: Better reporting of actual LSMs at boot lsm: make security_socket_getpeersec_stream() sockptr_t safe audit: Fix some kernel-doc warnings lsm: remove obsoleted comments for security hooks fs: edit a comment made in bad taste
2022-12-13mnt_idmapping: move ima-only helpers to imaChristian Brauner1-0/+24
The vfs{g,u}id_{gt,lt}_* helpers are currently not needed outside of ima and we shouldn't incentivize people to use them by placing them into the header. Let's just define them locally in the one file in ima where they are used. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
2022-12-13Merge tag 'fs.vfsuid.conversion.v6.2' of ↵Linus Torvalds1-16/+18
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping Pull vfsuid updates from Christian Brauner: "Last cycle we introduced the vfs{g,u}id_t types and associated helpers to gain type safety when dealing with idmapped mounts. That initial work already converted a lot of places over but there were still some left, This converts all remaining places that still make use of non-type safe idmapping helpers to rely on the new type safe vfs{g,u}id based helpers. Afterwards it removes all the old non-type safe helpers" * tag 'fs.vfsuid.conversion.v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping: fs: remove unused idmapping helpers ovl: port to vfs{g,u}id_t and associated helpers fuse: port to vfs{g,u}id_t and associated helpers ima: use type safe idmapping helpers apparmor: use type safe idmapping helpers caps: use type safe idmapping helpers fs: use type safe idmapping helpers mnt_idmapping: add missing helpers
2022-11-29ima: Fix hash dependency to correct algorithmTianjia Zhang1-1/+1
Commit d2825fa9365d ("crypto: sm3,sm4 - move into crypto directory") moves the SM3 and SM4 stand-alone library and the algorithm implementation for the Crypto API into the same directory, and the corresponding relationship of Kconfig is modified, CONFIG_CRYPTO_SM3/4 corresponds to the stand-alone library of SM3/4, and CONFIG_CRYPTO_SM3/4_GENERIC corresponds to the algorithm implementation for the Crypto API. Therefore, it is necessary for this module to depend on the correct algorithm. Fixes: d2825fa9365d ("crypto: sm3,sm4 - move into crypto directory") Cc: Jason A. Donenfeld <Jason@zx2c4.com> Cc: stable@vger.kernel.org # v5.19+ Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2022-11-19lsm,fs: fix vfs_getxattr_alloc() return type and caller error pathsPaul Moore4-13/+15
The vfs_getxattr_alloc() function currently returns a ssize_t value despite the fact that it only uses int values internally for return values. Fix this by converting vfs_getxattr_alloc() to return an int type and adjust the callers as necessary. As part of these caller modifications, some of the callers are fixed to properly free the xattr value buffer on both success and failure to ensure that memory is not leaked in the failure case. Reviewed-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2022-11-16ima: Fix misuse of dereference of pointer in template_desc_init_fields()Xiu Jianfeng1-2/+2
The input parameter @fields is type of struct ima_template_field ***, so when allocates array memory for @fields, the size of element should be sizeof(**field) instead of sizeof(*field). Actually the original code would not cause any runtime error, but it's better to make it logically right. Fixes: adf53a778a0a ("ima: new templates management mechanism") Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2022-11-03ima: Fix memory leak in __ima_inode_hash()Roberto Sassu1-1/+6
Commit f3cc6b25dcc5 ("ima: always measure and audit files in policy") lets measurement or audit happen even if the file digest cannot be calculated. As a result, iint->ima_hash could have been allocated despite ima_collect_measurement() returning an error. Since ima_hash belongs to a temporary inode metadata structure, declared at the beginning of __ima_inode_hash(), just add a kfree() call if ima_collect_measurement() returns an error different from -ENOMEM (in that case, ima_hash should not have been allocated). Cc: stable@vger.kernel.org Fixes: 280fe8367b0d ("ima: Always return a file measurement in ima_file_hash()") Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2022-11-03ima: Handle -ESTALE returned by ima_filter_rule_match()GUO Zihua1-9/+32
IMA relies on the blocking LSM policy notifier callback to update the LSM based IMA policy rules. When SELinux update its policies, IMA would be notified and starts updating all its lsm rules one-by-one. During this time, -ESTALE would be returned by ima_filter_rule_match() if it is called with a LSM rule that has not yet been updated. In ima_match_rules(), -ESTALE is not handled, and the LSM rule is considered a match, causing extra files to be measured by IMA. Fix it by re-initializing a temporary rule if -ESTALE is returned by ima_filter_rule_match(). The origin rule in the rule list would be updated by the LSM policy notifier callback. Fixes: b16942455193 ("ima: use the lsm policy update notifier") Signed-off-by: GUO Zihua <guozihua@huawei.com> Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2022-11-03ima: Simplify ima_lsm_copy_ruleGUO Zihua1-7/+3
Currently ima_lsm_copy_rule() set the arg_p field of the source rule to NULL, so that the source rule could be freed afterward. It does not make sense for this behavior to be inside a "copy" function. So move it outside and let the caller handle this field. ima_lsm_copy_rule() now produce a shallow copy of the original entry including args_p field. Meaning only the lsm.rule and the rule itself should be freed for the original rule. Thus, instead of calling ima_lsm_free_rule() which frees lsm.rule as well as args_p field, free the lsm.rule directly. Signed-off-by: GUO Zihua <guozihua@huawei.com> Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2022-11-03ima: Fix a potential NULL pointer access in ima_restore_measurement_listHuaxin Lu1-1/+4
In restore_template_fmt, when kstrdup fails, a non-NULL value will still be returned, which causes a NULL pointer access in template_desc_init_fields. Fixes: c7d09367702e ("ima: support restoring multiple template formats") Cc: stable@kernel.org Co-developed-by: Jiaming Li <lijiaming30@huawei.com> Signed-off-by: Jiaming Li <lijiaming30@huawei.com> Signed-off-by: Huaxin Lu <luhuaxin1@huawei.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2022-10-26ima: use type safe idmapping helpersChristian Brauner1-16/+18
We already ported most parts and filesystems over for v6.0 to the new vfs{g,u}id_t type and associated helpers for v6.0. Convert the remaining places so we can remove all the old helpers. This is a non-functional change. Reviewed-by: Seth Forshee (DigitalOcean) <sforshee@kernel.org> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
2022-10-20integrity: implement get and set acl hookChristian Brauner1-0/+9
The current way of setting and getting posix acls through the generic xattr interface is error prone and type unsafe. The vfs needs to interpret and fixup posix acls before storing or reporting it to userspace. Various hacks exist to make this work. The code is hard to understand and difficult to maintain in it's current form. Instead of making this work by hacking posix acls through xattr handlers we are building a dedicated posix acl api around the get and set inode operations. This removes a lot of hackiness and makes the codepaths easier to maintain. A lot of background can be found in [1]. So far posix acls were passed as a void blob to the security and integrity modules. Some of them like evm then proceed to interpret the void pointer and convert it into the kernel internal struct posix acl representation to perform their integrity checking magic. This is obviously pretty problematic as that requires knowledge that only the vfs is guaranteed to have and has lead to various bugs. Add a proper security hook for setting posix acls and pass down the posix acls in their appropriate vfs format instead of hacking it through a void pointer stored in the uapi format. I spent considerate time in the security module and integrity infrastructure and audited all codepaths. EVM is the only part that really has restrictions based on the actual posix acl values passed through it (e.g., i_mode). Before this dedicated hook EVM used to translate from the uapi posix acl format sent to it in the form of a void pointer into the vfs format. This is not a good thing. Instead of hacking around in the uapi struct give EVM the posix acls in the appropriate vfs format and perform sane permissions checks that mirror what it used to to in the generic xattr hook. IMA doesn't have any restrictions on posix acls. When posix acls are changed it just wants to update its appraisal status to trigger an EVM revalidation. The removal of posix acls is equivalent to passing NULL to the posix set acl hooks. This is the same as before through the generic xattr api. Link: https://lore.kernel.org/all/20220801145520.1532837-1-brauner@kernel.org [1] Acked-by: Paul Moore <paul@paul-moore.com> (LSM) Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>