kernel.git/security/integrity/evm/evm_crypto.c, branch linux-6.8.y

evm: Support multiple LSMs providing an xattr

2023-07-10T17:59:39Z

Currently, evm_inode_init_security() processes a single LSM xattr from the array passed by security_inode_init_security(), and calculates the HMAC on it and other inode metadata. As the LSM infrastructure now can pass to EVM an array with multiple xattrs, scan them until the terminator (xattr name NULL), and calculate the HMAC on all of them. Also, double check that the xattrs array terminator is the first non-filled slot (obtained with lsm_get_xattr_slot()). Consumers of the xattrs array, such as the initxattrs() callbacks, rely on the terminator. Finally, change the name of the lsm_xattr parameter of evm_init_hmac() to xattrs, to reflect the new type of information passed. Signed-off-by: Roberto Sassu Reviewed-by: Mimi Zohar Acked-by: Mimi Zohar Signed-off-by: Paul Moore

evm: Fix build warnings

2023-06-06T12:51:11Z

Fix build warnings (function parameters description) for evm_read_protected_xattrs(), evm_set_key() and evm_verifyxattr(). Fixes: 7626676320f3 ("evm: provide a function to set the EVM key from the kernel") # v4.5+ Fixes: 8314b6732ae4 ("ima: Define new template fields xattrnames, xattrlengths and xattrvalues") # v5.14+ Fixes: 2960e6cb5f7c ("evm: additional parameter to pass integrity cache entry 'iint'") # v3.2+ Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar

Merge tag 'integrity-v6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity

2023-02-22T20:36:25Z

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

evm: call dump_security_xattr() in all cases to remove code duplication

2023-01-31T17:47:16Z

Currently dump_security_xattr() is used to dump security xattr value which is larger than 64 bytes, otherwise, pr_debug() is used. In order to remove code duplication, refactor dump_security_xattr() and call it in all cases. Signed-off-by: Xiu Jianfeng Signed-off-by: Mimi Zohar

fs: port xattr to mnt_idmap

2023-01-19T08:24:28Z

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 Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner (Microsoft)

fs: port ->permission() to pass mnt_idmap

2023-01-19T08:24:28Z

lsm,fs: fix vfs_getxattr_alloc() return type and caller error paths

2022-11-18T22:07:03Z

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 Reviewed-by: Mimi Zohar Signed-off-by: Paul Moore

Revert "evm: Fix memleak in init_desc"

2022-06-15T18:03:47Z

This reverts commit ccf11dbaa07b328fa469415c362d33459c140a37. Commit ccf11dbaa07b ("evm: Fix memleak in init_desc") said there is memleak in init_desc. That may be incorrect, as we can see, tmp_tfm is saved in one of the two global variables hmac_tfm or evm_tfm[hash_algo], then if init_desc is called next time, there is no need to alloc tfm again, so in the error path of kmalloc desc or crypto_shash_init(desc), It is not a problem without freeing tmp_tfm. And also that commit did not reset the global variable to NULL after freeing tmp_tfm and this makes *tfm a dangling pointer which may cause a UAF issue. Reported-by: Guozihua (Scott) Signed-off-by: Xiu Jianfeng Signed-off-by: Mimi Zohar

evm: Clean up some variables

2022-05-16T12:14:38Z

Make hmac_tfm static since it's not used anywhere else besides the file it is in. Remove declaration of hash_tfm since it doesn't exist. Signed-off-by: Stefan Berger Signed-off-by: Mimi Zohar

evm: Check xattr size discrepancy between kernel and user

2021-06-21T12:34:21Z

The kernel and the user obtain an xattr value in two different ways: kernel (EVM): uses vfs_getxattr_alloc() which obtains the xattr value from the filesystem handler (raw value); user (ima-evm-utils): uses vfs_getxattr() which obtains the xattr value from the LSMs (normalized value). Normally, this does not have an impact unless security.selinux is set with setfattr, with a value not terminated by '\0' (this is not the recommended way, security.selinux should be set with the appropriate tools such as chcon and restorecon). In this case, the kernel and the user see two different xattr values: the former sees the xattr value without '\0' (raw value), the latter sees the value with '\0' (value normalized by SELinux). This could result in two different verification outcomes from EVM and ima-evm-utils, if a signature was calculated with a security.selinux value terminated by '\0' and the value set in the filesystem is not terminated by '\0'. The former would report verification failure due to the missing '\0', while the latter would report verification success (because it gets the normalized value with '\0'). This patch mitigates this issue by comparing in evm_calc_hmac_or_hash() the size of the xattr returned by the two xattr functions and by warning the user if there is a discrepancy. Signed-off-by: Roberto Sassu Suggested-by: Mimi Zohar Signed-off-by: Mimi Zohar