Skip to content

Commit

Permalink
KEYS: Fix UID check in keyctl_get_persistent()
Browse files Browse the repository at this point in the history
If the UID is specified by userspace when calling the KEYCTL_GET_PERSISTENT
function and the process does not have the CAP_SETUID capability, then the
function will return -EPERM if the current process's uid, suid, euid and fsuid
all match the requested UID.  This is incorrect.

Fix it such that when a non-privileged caller requests a persistent keyring by
a specific UID they can only request their own (ie. the specified UID matches
either then process's UID or the process's EUID).

This can be tested by logging in as the user and doing:

	keyctl get_persistent @p
	keyctl get_persistent @p `id -u`
	keyctl get_persistent @p 0

The first two should successfully print the same key ID.  The third should do
the same if called by UID 0 or indicate Operation Not Permitted otherwise.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Stephen Gallagher <sgallagh@redhat.com>
  • Loading branch information
David Howells committed Nov 6, 2013
1 parent dbed714 commit fbf8c53
Showing 1 changed file with 2 additions and 4 deletions.
6 changes: 2 additions & 4 deletions security/keys/persistent.c
Original file line number Diff line number Diff line change
Expand Up @@ -144,10 +144,8 @@ long keyctl_get_persistent(uid_t _uid, key_serial_t destid)
/* You can only see your own persistent cache if you're not
* sufficiently privileged.
*/
if (uid_eq(uid, current_uid()) &&
uid_eq(uid, current_suid()) &&
uid_eq(uid, current_euid()) &&
uid_eq(uid, current_fsuid()) &&
if (!uid_eq(uid, current_uid()) &&
!uid_eq(uid, current_euid()) &&
!ns_capable(ns, CAP_SETUID))
return -EPERM;
}
Expand Down

0 comments on commit fbf8c53

Please sign in to comment.