user/sven/linux.git/security, branch v5.9.8

fs/kernel_read_file: Remove FIRMWARE_PREALLOC_BUFFER enum

2020-11-05T10:51:35Z

commit c307459b9d1fcb8bbf3ea5a4162979532322ef77 upstream. FIRMWARE_PREALLOC_BUFFER is a "how", not a "what", and confuses the LSMs that are interested in filtering between types of things. The "how" should be an internal detail made uninteresting to the LSMs. Fixes: a098ecd2fa7d ("firmware: support loading into a pre-allocated buffer") Fixes: fd90bc559bfb ("ima: based on policy verify firmware signatures (pre-allocated buffer)") Fixes: 4f0496d8ffa3 ("ima: based on policy warn about loading firmware (pre-allocated buffer)") Signed-off-by: Kees Cook Reviewed-by: Mimi Zohar Reviewed-by: Luis Chamberlain Acked-by: Scott Branden Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201002173828.2099543-2-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

selinux: access policycaps with READ_ONCE/WRITE_ONCE

2020-11-05T10:51:21Z

[ Upstream commit e8ba53d0023a76ba0f50e6ee3e6288c5442f9d33 ] Use READ_ONCE/WRITE_ONCE for all accesses to the selinux_state.policycaps booleans to prevent compiler mischief. Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Sasha Levin

evm: Check size of security.evm before using it

2020-11-01T11:47:08Z

commit 455b6c9112eff8d249e32ba165742085678a80a4 upstream. This patch checks the size for the EVM_IMA_XATTR_DIGSIG and EVM_XATTR_PORTABLE_DIGSIG types to ensure that the algorithm is read from the buffer returned by vfs_getxattr_alloc(). Cc: stable@vger.kernel.org # 4.19.x Fixes: 5feeb61183dde ("evm: Allow non-SHA1 digital signatures") Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman

ima: Fix NULL pointer dereference in ima_file_hash

2020-10-29T09:11:21Z

[ Upstream commit aa662fc04f5b290b3979332588bf8d812b189962 ] ima_file_hash can be called when there is no iint->ima_hash available even though the inode exists in the integrity cache. It is fairly common for a file to not have a hash. (e.g. an mknodat, prior to the file being closed). Another example where this can happen (suggested by Jann Horn): Process A does: while(1) { unlink("/tmp/imafoo"); fd = open("/tmp/imafoo", O_RDWR|O_CREAT|O_TRUNC, 0700); if (fd == -1) { perror("open"); continue; } write(fd, "A", 1); close(fd); } and Process B does: while (1) { int fd = open("/tmp/imafoo", O_RDONLY); if (fd == -1) continue; char *mapping = mmap(NULL, 0x1000, PROT_READ|PROT_EXEC, MAP_PRIVATE, fd, 0); if (mapping != MAP_FAILED) munmap(mapping, 0x1000); close(fd); } Due to the race to get the iint->mutex between ima_file_hash and process_measurement iint->ima_hash could still be NULL. Fixes: 6beea7afcc72 ("ima: add the ability to query the cached hash of a given file") Signed-off-by: KP Singh Reviewed-by: Florent Revest Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin

ima: Fail rule parsing when asymmetric key measurement isn't supportable

2020-10-29T09:11:15Z

[ Upstream commit 48ce1ddce16b0d1e3ff948da40a0d5125a4ee1a0 ] Measuring keys is currently only supported for asymmetric keys. In the future, this might change. For now, the "func=KEY_CHECK" and "keyrings=" options are only appropriate when CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS is enabled. Make this clear at policy load so that IMA policy authors don't assume that these policy language constructs are supported. Fixes: 2b60c0ecedf8 ("IMA: Read keyrings= option from the IMA policy") Fixes: 5808611cccb2 ("IMA: Add KEY_CHECK func to measure keys") Suggested-by: Nayna Jain Signed-off-by: Tyler Hicks Reviewed-by: Lakshmi Ramasubramanian Reviewed-by: Nayna Jain Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin

ima: Pre-parse the list of keyrings in a KEY_CHECK rule

2020-10-29T09:11:15Z

[ Upstream commit 176377d97d6a3fae971ecb1f47d9b9cb7dab05ef ] The ima_keyrings buffer was used as a work buffer for strsep()-based parsing of the "keyrings=" option of an IMA policy rule. This parsing was re-performed each time an asymmetric key was added to a kernel keyring for each loaded policy rule that contained a "keyrings=" option. An example rule specifying this option is: measure func=KEY_CHECK keyrings=a|b|c The rule says to measure asymmetric keys added to any of the kernel keyrings named "a", "b", or "c". The size of the buffer size was equal to the size of the largest "keyrings=" value seen in a previously loaded rule (5 + 1 for the NUL-terminator in the previous example) and the buffer was pre-allocated at the time of policy load. The pre-allocated buffer approach suffered from a couple bugs: 1) There was no locking around the use of the buffer so concurrent key add operations, to two different keyrings, would result in the strsep() loop of ima_match_keyring() to modify the buffer at the same time. This resulted in unexpected results from ima_match_keyring() and, therefore, could cause unintended keys to be measured or keys to not be measured when IMA policy intended for them to be measured. 2) If the kstrdup() that initialized entry->keyrings in ima_parse_rule() failed, the ima_keyrings buffer was freed and set to NULL even when a valid KEY_CHECK rule was previously loaded. The next KEY_CHECK event would trigger a call to strcpy() with a NULL destination pointer and crash the kernel. Remove the need for a pre-allocated global buffer by parsing the list of keyrings in a KEY_CHECK rule at the time of policy load. The ima_rule_entry will contain an array of string pointers which point to the name of each keyring specified in the rule. No string processing needs to happen at the time of asymmetric key add so iterating through the list and doing a string comparison is all that's required at the time of policy check. In the process of changing how the "keyrings=" policy option is handled, a couple additional bugs were fixed: 1) The rule parser accepted rules containing invalid "keyrings=" values such as "a|b||c", "a|b|", or simply "|". 2) The /sys/kernel/security/ima/policy file did not display the entire "keyrings=" value if the list of keyrings was longer than what could fit in the fixed size tbuf buffer in ima_policy_show(). Fixes: 5c7bac9fb2c5 ("IMA: pre-allocate buffer to hold keyrings string") Fixes: 2b60c0ecedf8 ("IMA: Read keyrings= option from the IMA policy") Signed-off-by: Tyler Hicks Reviewed-by: Lakshmi Ramasubramanian Reviewed-by: Nayna Jain Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin

ima: Don't ignore errors from crypto_shash_update()

2020-10-29T09:10:59Z

commit 60386b854008adc951c470067f90a2d85b5d520f upstream. Errors returned by crypto_shash_update() are not checked in ima_calc_boot_aggregate_tfm() and thus can be overwritten at the next iteration of the loop. This patch adds a check after calling crypto_shash_update() and returns immediately if the result is not zero. Cc: stable@vger.kernel.org Fixes: 3323eec921efd ("integrity: IMA as an integrity service provider") Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman

Merge tag 'fixes-v5.9a' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security

2020-09-15T23:26:57Z

Pull security layer fix from James Morris: "A device_cgroup RCU warning fix from Amol Grover" * tag 'fixes-v5.9a' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: device_cgroup: Fix RCU list debugging warning

treewide: Use fallthrough pseudo-keyword

2020-08-23T22:36:59Z

Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva

device_cgroup: Fix RCU list debugging warning

2020-08-20T18:25:03Z

exceptions may be traversed using list_for_each_entry_rcu() outside of an RCU read side critical section BUT under the protection of decgroup_mutex. Hence add the corresponding lockdep expression to fix the following false-positive warning: [ 2.304417] ============================= [ 2.304418] WARNING: suspicious RCU usage [ 2.304420] 5.5.4-stable #17 Tainted: G E [ 2.304422] ----------------------------- [ 2.304424] security/device_cgroup.c:355 RCU-list traversed in non-reader section!! Signed-off-by: Amol Grover Signed-off-by: James Morris