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

efi: Only print errors about failing to get certs if EFI vars are found

2020-03-12T12:00:14Z

[ Upstream commit 3be54d558c75562e42bc83d665df024bd79d399b ] If CONFIG_LOAD_UEFI_KEYS is enabled, the kernel attempts to load the certs from the db, dbx and MokListRT EFI variables into the appropriate keyrings. But it just assumes that the variables will be present and prints an error if the certs can't be loaded, even when is possible that the variables may not exist. For example the MokListRT variable will only be present if shim is used. So only print an error message about failing to get the certs list from an EFI variable if this is found. Otherwise these printed errors just pollute the kernel log ring buffer with confusing messages like the following: [ 5.427251] Couldn't get size: 0x800000000000000e [ 5.427261] MODSIGN: Couldn't get UEFI db list [ 5.428012] Couldn't get size: 0x800000000000000e [ 5.428023] Couldn't get UEFI MokListRT Reported-by: Hans de Goede Signed-off-by: Javier Martinez Canillas Tested-by: Hans de Goede Acked-by: Ard Biesheuvel Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin

ima: ima/lsm policy rule loading logic bug fixes

2020-03-05T15:43:49Z

commit 483ec26eed42bf050931d9a5c5f9f0b5f2ad5f3b upstream. Keep the ima policy rules around from the beginning even if they appear invalid at the time of loading, as they may become active after an lsm policy load. However, loading a custom IMA policy with unknown LSM labels is only safe after we have transitioned from the "built-in" policy rules to a custom IMA policy. Patch also fixes the rule re-use during the lsm policy reload and makes some prints a bit more human readable. Changelog: v4: - Do not allow the initial policy load refer to non-existing lsm rules. v3: - Fix too wide policy rule matching for non-initialized LSMs v2: - Fix log prints Fixes: b16942455193 ("ima: use the lsm policy update notifier") Cc: Casey Schaufler Reported-by: Mimi Zohar Signed-off-by: Janne Karhunen Signed-off-by: Konsta Karsisto Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman

selinux: ensure we cleanup the internal AVC counters on error in avc_update()

2020-02-24T07:36:39Z

[ Upstream commit 030b995ad9ece9fa2d218af4429c1c78c2342096 ] In AVC update we don't call avc_node_kill() when avc_xperms_populate() fails, resulting in the avc->avc_cache.active_nodes counter having a false value. In last patch this changes was missed , so correcting it. Fixes: fa1aa143ac4a ("selinux: extended permissions for ioctls") Signed-off-by: Jaihind Yadav Signed-off-by: Ravi Kumar Siddojigari [PM: merge fuzz, minor description cleanup] Signed-off-by: Paul Moore Signed-off-by: Sasha Levin

selinux: ensure we cleanup the internal AVC counters on error in avc_insert()

2020-02-24T07:36:34Z

[ Upstream commit d8db60cb23e49a92cf8cada3297395c7fa50fdf8 ] Fix avc_insert() to call avc_node_kill() if we've already allocated an AVC node and the code fails to insert the node in the cache. Fixes: fa1aa143ac4a ("selinux: extended permissions for ioctls") Reported-by: rsiddoji@codeaurora.org Suggested-by: Stephen Smalley Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Sasha Levin

selinux: fall back to ref-walk if audit is required

2020-02-14T21:34:20Z

commit 0188d5c025ca8fe756ba3193bd7d150139af5a88 upstream. commit bda0be7ad994 ("security: make inode_follow_link RCU-walk aware") passed down the rcu flag to the SELinux AVC, but failed to adjust the test in slow_avc_audit() to also return -ECHILD on LSM_AUDIT_DATA_DENTRY. Previously, we only returned -ECHILD if generating an audit record with LSM_AUDIT_DATA_INODE since this was only relevant from inode_permission. Move the handling of MAY_NOT_BLOCK to avc_audit() and its inlined equivalent in selinux_inode_permission() immediately after we determine that audit is required, and always fall back to ref-walk in this case. Fixes: bda0be7ad994 ("security: make inode_follow_link RCU-walk aware") Reported-by: Will Deacon Suggested-by: Al Viro Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman

selinux: fix regression introduced by move_mount(2) syscall

2020-02-14T21:34:19Z

commit 98aa00345de54b8340dc2ddcd87f446d33387b5e upstream. commit 2db154b3ea8e ("vfs: syscall: Add move_mount(2) to move mounts around") introduced a new move_mount(2) system call and a corresponding new LSM security_move_mount hook but did not implement this hook for any existing LSM. This creates a regression for SELinux with respect to consistent checking of mounts; the existing selinux_mount hook checks mounton permission to the mount point path. Provide a SELinux hook implementation for move_mount that applies this same check for consistency. In the future we may wish to add a new move_mount filesystem permission and check as well, but this addresses the immediate regression. Fixes: 2db154b3ea8e ("vfs: syscall: Add move_mount(2) to move mounts around") Signed-off-by: Stephen Smalley Reviewed-by: Ondrej Mosnacek Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman

selinux: revert "stop passing MAY_NOT_BLOCK to the AVC upon follow_link"

2020-02-14T21:34:19Z

commit 1a37079c236d55fb31ebbf4b59945dab8ec8764c upstream. This reverts commit e46e01eebbbc ("selinux: stop passing MAY_NOT_BLOCK to the AVC upon follow_link"). The correct fix is to instead fall back to ref-walk if audit is required irrespective of the specific audit data type. This is done in the next commit. Fixes: e46e01eebbbc ("selinux: stop passing MAY_NOT_BLOCK to the AVC upon follow_link") Reported-by: Will Deacon Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman

broken ping to ipv6 linklocal addresses on debian buster

2020-02-11T12:35:43Z

commit 87fbfffcc89b92a4281b0aa53bd06af714087889 upstream. I am seeing ping failures to IPv6 linklocal addresses with Debian buster. Easiest example to reproduce is: $ ping -c1 -w1 ff02::1%eth1 connect: Invalid argument $ ping -c1 -w1 ff02::1%eth1 PING ff02::01%eth1(ff02::1%eth1) 56 data bytes 64 bytes from fe80::e0:f9ff:fe0c:37%eth1: icmp_seq=1 ttl=64 time=0.059 ms git bisect traced the failure to commit b9ef5513c99b ("smack: Check address length before reading address family") Arguably ping is being stupid since the buster version is not setting the address family properly (ping on stretch for example does): $ strace -e connect ping6 -c1 -w1 ff02::1%eth1 connect(5, {sa_family=AF_UNSPEC, sa_data="\4\1\0\0\0\0\377\2\0\0\0\0\0\0\0\0\0\0\0\0\0\1\3\0\0\0"}, 28) = -1 EINVAL (Invalid argument) but the command works fine on kernels prior to this commit, so this is breakage which goes against the Linux paradigm of "don't break userspace" Cc: stable@vger.kernel.org Reported-by: David Ahern Suggested-by: Tetsuo Handa Signed-off-by: Casey Schaufler Signed-off-by: Greg Kroah-Hartman security/smack/smack_lsm.c | 41 +++++++++++++++++++---------------------- security/smack/smack_lsm.c | 41 +++++++++++++++++++---------------------- 1 file changed, 19 insertions(+), 22 deletions(-)

tomoyo: Use atomic_t for statistics counter

2020-02-05T21:22:41Z

commit a8772fad0172aeae339144598b809fd8d4823331 upstream. syzbot is reporting that there is a race at tomoyo_stat_update() [1]. Although it is acceptable to fail to track exact number of times policy was updated, convert to atomic_t because this is not a hot path. [1] https://syzkaller.appspot.com/bug?id=a4d7b973972eeed410596e6604580e0133b0fc04 Reported-by: syzbot Signed-off-by: Tetsuo Handa Signed-off-by: Greg Kroah-Hartman

tomoyo: Suppress RCU warning at list_for_each_entry_rcu().

2020-01-17T18:49:05Z

[ Upstream commit 6bd5ce6089b561f5392460bfb654dea89356ab1b ] John Garry has reported that allmodconfig kernel on arm64 causes flood of "RCU-list traversed in non-reader section!!" warning. I don't know what change caused this warning, but this warning is safe because TOMOYO uses SRCU lock instead. Let's suppress this warning by explicitly telling that the caller is holding SRCU lock. Reported-and-tested-by: John Garry Signed-off-by: Tetsuo Handa Signed-off-by: Sasha Levin