linux.git/security/keys, branch v3.13-rc2

KEYS: Fix keyring content gc scanner

2013-11-14T14:09:53+00:00

Key pointers stored in the keyring are marked in bit 1 to indicate if they
point to a keyring.  We need to strip off this bit before using the pointer
when iterating over the keyring for the purpose of looking for links to garbage
collect.

This means that expirable keyrings aren't correctly expiring because the
checker is seeing their key pointer with 2 added to it.

Since the fix for this involves knowing about the internals of the keyring,
key_gc_keyring() is moved to keyring.c and merged into keyring_gc().

This can be tested by:

	echo 2 >/proc/sys/kernel/keys/gc_delay
	keyctl timeout `keyctl add keyring qwerty "" @s` 2
	cat /proc/keys
	sleep 5; cat /proc/keys

which should see a keyring called "qwerty" appear in the session keyring and
then disappear after it expires, and:

	echo 2 >/proc/sys/kernel/keys/gc_delay
	a=`keyctl get_persistent @s`
	b=`keyctl add keyring 0 "" $a`
	keyctl add user a a $b
	keyctl timeout $b 2
	cat /proc/keys
	sleep 5; cat /proc/keys

which should see a keyring called "0" with a key called "a" in it appear in the
user's persistent keyring (which will be attached to the session keyring) and
then both the "0" keyring and the "a" key should disappear when the "0" keyring
expires.

Signed-off-by: David Howells 
Acked-by: Simo Sorce

KEYS: Fix error handling in big_key instantiation

2013-11-13T16:51:06+00:00

In the big_key_instantiate() function we return 0 if kernel_write() returns us
an error rather than returning an error.  This can potentially lead to
dentry_open() giving a BUG when called from big_key_read() with an unset
tmpfile path.

	------------[ cut here ]------------
	kernel BUG at fs/open.c:798!
	...
	RIP: 0010:[] dentry_open+0xd1/0xe0
	...
	Call Trace:
	 [] big_key_read+0x55/0x100
	 [] keyctl_read_key+0xb4/0xe0
	 [] SyS_keyctl+0xf8/0x1d0
	 [] system_call_fastpath+0x16/0x1b


Signed-off-by: David Howells 
Reviewed-by: Stephen Gallagher

KEYS: Fix UID check in keyctl_get_persistent()

2013-11-06T14:01:51+00:00

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 
Acked-by: Stephen Gallagher

KEYS: fix error return code in big_key_instantiate()

2013-10-30T12:54:29+00:00

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun 
Signed-off-by: David Howells

KEYS: Fix keyring quota misaccounting on key replacement and unlink

2013-10-30T11:15:24+00:00

If a key is displaced from a keyring by a matching one, then four more bytes
of quota are allocated to the keyring - despite the fact that the keyring does
not change in size.

Further, when a key is unlinked from a keyring, the four bytes of quota
allocated the link isn't recovered and returned to the user's pool.

The first can be tested by repeating:

	keyctl add big_key a fred @s
	cat /proc/key-users

(Don't put it in a shell loop otherwise the garbage collector won't have time
to clear the displaced keys, thus affecting the result).

This was causing the kerberos keyring to run out of room fairly quickly.

The second can be tested by:

	cat /proc/key-users
	a=`keyctl add user a a @s`
	cat /proc/key-users
	keyctl unlink $a
	sleep 1 # Give RCU a chance to delete the key
	cat /proc/key-users

assuming no system activity that otherwise adds/removes keys, the amount of
key data allocated should go up (say 40/20000 -> 47/20000) and then return to
the original value at the end.

Reported-by: Stephen Gallagher 
Signed-off-by: David Howells

KEYS: Fix a race between negating a key and reading the error set

2013-10-30T11:15:24+00:00

key_reject_and_link() marking a key as negative and setting the error with
which it was negated races with keyring searches and other things that read
that error.

The fix is to switch the order in which the assignments are done in
key_reject_and_link() and to use memory barriers.

Kudos to Dave Wysochanski  and Scott Mayhew
 for tracking this down.

This may be the cause of:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
IP: [] wait_for_key_construction+0x31/0x80
PGD c6b2c3067 PUD c59879067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
CPU 0
Modules linked in: ...

Pid: 13359, comm: amqzxma0 Not tainted 2.6.32-358.20.1.el6.x86_64 #1 IBM System x3650 M3 -[7945PSJ]-/00J6159
RIP: 0010:[] wait_for_key_construction+0x31/0x80
RSP: 0018:ffff880c6ab33758  EFLAGS: 00010246
RAX: ffffffff81219080 RBX: 0000000000000000 RCX: 0000000000000002
RDX: ffffffff81219060 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff880c6ab33768 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: ffff880adfcbce40
R13: ffffffffa03afb84 R14: ffff880adfcbce40 R15: ffff880adfcbce43
FS:  00007f29b8042700(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000070 CR3: 0000000c613dc000 CR4: 00000000000007f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process amqzxma0 (pid: 13359, threadinfo ffff880c6ab32000, task ffff880c610deae0)
Stack:
 ffff880adfcbce40 0000000000000000 ffff880c6ab337b8 ffffffff81219695
 0000000000000000 ffff880a000000d0 ffff880c6ab337a8 000000000000000f
 ffffffffa03afb93 000000000000000f ffff88186c7882c0 0000000000000014
Call Trace:
 [] request_key+0x65/0xa0
 [] nfs_idmap_request_key+0xc5/0x170 [nfs]
 [] nfs_idmap_lookup_id+0x34/0x80 [nfs]
 [] nfs_map_group_to_gid+0x75/0xa0 [nfs]
 [] decode_getfattr_attrs+0xbdd/0xfb0 [nfs]
 [] ? __dequeue_entity+0x30/0x50
 [] ? __switch_to+0x26e/0x320
 [] decode_getfattr+0x83/0xe0 [nfs]
 [] ? nfs4_xdr_dec_getattr+0x0/0xa0 [nfs]
 [] nfs4_xdr_dec_getattr+0x8f/0xa0 [nfs]
 [] rpcauth_unwrap_resp+0x84/0xb0 [sunrpc]
 [] ? nfs4_xdr_dec_getattr+0x0/0xa0 [nfs]
 [] call_decode+0x1b3/0x800 [sunrpc]
 [] ? wake_bit_function+0x0/0x50
 [] ? call_decode+0x0/0x800 [sunrpc]
 [] __rpc_execute+0x77/0x350 [sunrpc]
 [] ? bit_waitqueue+0x17/0xd0
 [] rpc_execute+0x61/0xa0 [sunrpc]
 [] rpc_run_task+0x75/0x90 [sunrpc]
 [] rpc_call_sync+0x42/0x70 [sunrpc]
 [] _nfs4_call_sync+0x30/0x40 [nfs]
 [] _nfs4_proc_getattr+0xac/0xc0 [nfs]
 [] ? futex_wait+0x227/0x380
 [] nfs4_proc_getattr+0x56/0x80 [nfs]
 [] __nfs_revalidate_inode+0xe3/0x220 [nfs]
 [] nfs_revalidate_mapping+0x4e/0x170 [nfs]
 [] nfs_file_read+0x77/0x130 [nfs]
 [] do_sync_read+0xfa/0x140
 [] ? autoremove_wake_function+0x0/0x40
 [] ? apic_timer_interrupt+0xe/0x20
 [] ? common_interrupt+0xe/0x13
 [] ? selinux_file_permission+0xfb/0x150
 [] ? security_file_permission+0x16/0x20
 [] vfs_read+0xb5/0x1a0
 [] sys_read+0x51/0x90
 [] ? __audit_syscall_exit+0x265/0x290
 [] system_call_fastpath+0x16/0x1b

Signed-off-by: David Howells 
cc: Dave Wysochanski 
cc: Scott Mayhew

KEYS: Make BIG_KEYS boolean

2013-10-30T11:15:23+00:00

Having the big_keys functionality as a module is very marginally useful.
The userspace code that would use this functionality will get odd error
messages from the keys layer if the module isn't loaded.  The code itself
is fairly small, so just have this as a boolean option and not a tristate.

Signed-off-by: Josh Boyer 
Signed-off-by: David Howells

KEYS: initialize root uid and session keyrings early

2013-09-25T16:17:01+00:00

In order to create the integrity keyrings (eg. _evm, _ima), root's
uid and session keyrings need to be initialized early.

Signed-off-by: Mimi Zohar 
Signed-off-by: David Howells

KEYS: Add a 'trusted' flag and a 'trusted only' flag

2013-09-25T16:17:01+00:00

Add KEY_FLAG_TRUSTED to indicate that a key either comes from a trusted source
or had a cryptographic signature chain that led back to a trusted key the
kernel already possessed.

Add KEY_FLAGS_TRUSTED_ONLY to indicate that a keyring will only accept links to
keys marked with KEY_FLAGS_TRUSTED.

Signed-off-by: David Howells 
Reviewed-by: Kees Cook

KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches

2013-09-24T09:35:19+00:00

Add support for per-user_namespace registers of persistent per-UID kerberos
caches held within the kernel.

This allows the kerberos cache to be retained beyond the life of all a user's
processes so that the user's cron jobs can work.

The kerberos cache is envisioned as a keyring/key tree looking something like:

	struct user_namespace
	  \___ .krb_cache keyring		- The register
		\___ _krb.0 keyring		- Root's Kerberos cache
		\___ _krb.5000 keyring		- User 5000's Kerberos cache
		\___ _krb.5001 keyring		- User 5001's Kerberos cache
			\___ tkt785 big_key	- A ccache blob
			\___ tkt12345 big_key	- Another ccache blob

Or possibly:

	struct user_namespace
	  \___ .krb_cache keyring		- The register
		\___ _krb.0 keyring		- Root's Kerberos cache
		\___ _krb.5000 keyring		- User 5000's Kerberos cache
		\___ _krb.5001 keyring		- User 5001's Kerberos cache
			\___ tkt785 keyring	- A ccache
				\___ krbtgt/REDHAT.COM@REDHAT.COM big_key
				\___ http/REDHAT.COM@REDHAT.COM user
				\___ afs/REDHAT.COM@REDHAT.COM user
				\___ nfs/REDHAT.COM@REDHAT.COM user
				\___ krbtgt/KERNEL.ORG@KERNEL.ORG big_key
				\___ http/KERNEL.ORG@KERNEL.ORG big_key

What goes into a particular Kerberos cache is entirely up to userspace.  Kernel
support is limited to giving you the Kerberos cache keyring that you want.

The user asks for their Kerberos cache by:

	krb_cache = keyctl_get_krbcache(uid, dest_keyring);

The uid is -1 or the user's own UID for the user's own cache or the uid of some
other user's cache (requires CAP_SETUID).  This permits rpc.gssd or whatever to
mess with the cache.

The cache returned is a keyring named "_krb." that the possessor can read,
search, clear, invalidate, unlink from and add links to.  Active LSMs get a
chance to rule on whether the caller is permitted to make a link.

Each uid's cache keyring is created when it first accessed and is given a
timeout that is extended each time this function is called so that the keyring
goes away after a while.  The timeout is configurable by sysctl but defaults to
three days.

Each user_namespace struct gets a lazily-created keyring that serves as the
register.  The cache keyrings are added to it.  This means that standard key
search and garbage collection facilities are available.

The user_namespace struct's register goes away when it does and anything left
in it is then automatically gc'd.

Signed-off-by: David Howells 
Tested-by: Simo Sorce 
cc: Serge E. Hallyn 
cc: Eric W. Biederman