linux-stable.git/security, branch v5.4.22

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

2020-02-24T07:36:39+00:00

[ 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:34+00:00

[ 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:20+00:00

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:19+00:00

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:19+00:00

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:43+00:00

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:41+00:00

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:05+00:00

[ 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

apparmor: fix aa_xattrs_match() may sleep while holding a RCU lock

2020-01-09T09:20:00+00:00

commit 8c62ed27a12c00e3db1c9f04bc0f272bdbb06734 upstream.

aa_xattrs_match() is unfortunately calling vfs_getxattr_alloc() from a
context protected by an rcu_read_lock. This can not be done as
vfs_getxattr_alloc() may sleep regardles of the gfp_t value being
passed to it.

Fix this by breaking the rcu_read_lock on the policy search when the
xattr match feature is requested and restarting the search if a policy
changes occur.

Fixes: 8e51f9087f40 ("apparmor: Add support for attaching profiles via xattr, presence and value")
Reported-by: Jia-Ju Bai 
Reported-by: Al Viro 
Signed-off-by: John Johansen 
Signed-off-by: Greg Kroah-Hartman

tomoyo: Don't use nifty names on sockets.

2020-01-04T18:18:42+00:00

commit 6f7c41374b62fd80bbd8aae3536c43688c54d95e upstream.

syzbot is reporting that use of SOCKET_I()->sk from open() can result in
use after free problem [1], for socket's inode is still reachable via
/proc/pid/fd/n despite destruction of SOCKET_I()->sk already completed.

At first I thought that this race condition applies to only open/getattr
permission checks. But James Morris has pointed out that there are more
permission checks where this race condition applies to. Thus, get rid of
tomoyo_get_socket_name() instead of conditionally bypassing permission
checks on sockets. As a side effect of this patch,
"socket:[family=\$:type=\$:protocol=\$]" in the policy files has to be
rewritten to "socket:[\$]".

[1] https://syzkaller.appspot.com/bug?id=73d590010454403d55164cca23bd0565b1eb3b74

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
Reported-by: James Morris 
Signed-off-by: Greg Kroah-Hartman