Eric Biggers 539255aea8 KEYS: prevent creating a different user's keyrings ... commit 237bbd29f7a049d310d907f4b2716a7feef9abf3 upstream. It was possible for an unprivileged user to create the user and user session keyrings for another user. For example: sudo -u '#3000' sh -c 'keyctl add keyring _uid.4000 "" @u keyctl add keyring _uid_ses.4000 "" @u sleep 15' & sleep 1 sudo -u '#4000' keyctl describe @u sudo -u '#4000' keyctl describe @us This is problematic because these "fake" keyrings won't have the right permissions. In particular, the user who created them first will own them and will have full access to them via the possessor permissions, which can be used to compromise the security of a user's keys: -4: alswrv-----v------------ 3000 0 keyring: _uid.4000 -5: alswrv-----v------------ 3000 0 keyring: _uid_ses.4000 Fix it by marking user and user session keyrings with a flag KEY_FLAG_UID_KEYRING. Then, when searching for a user or user session keyring by name, skip all keyrings that don't have the flag set. Fixes: 69664cf16a ("keys: don't generate user and user session keyrings unless they're accessed") Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>		2017-10-05 09:41:45 +02:00
..
apparmor	apparmor: fix change_hat not finding hat after policy replacement	2016-12-02 09:09:01 +01:00
integrity	ima: accept previously set IMA_NEW_FILE	2017-05-25 14:30:09 +02:00
keys	KEYS: prevent creating a different user's keyrings	2017-10-05 09:41:45 +02:00
selinux	selinux: fix off-by-one in setprocattr	2017-02-14 15:22:50 -08:00
smack	security: let security modules use PTRACE_MODE_* with bitmasks	2016-03-03 15:07:32 -08:00
tomoyo
yama	security: let security modules use PTRACE_MODE_* with bitmasks	2016-03-03 15:07:32 -08:00
commoncap.c	ptrace: use fsuid, fsgid, effective creds for fs access checks	2016-02-25 12:01:16 -08:00
device_cgroup.c
inode.c
Kconfig
lsm_audit.c
Makefile
min_addr.c
security.c