linux-stable.git/security, branch v3.12.74

KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings

2017-05-09T06:19:32+00:00

commit c9f838d104fed6f2f61d68164712e3204bf5271b upstream.

This fixes CVE-2017-7472.

Running the following program as an unprivileged user exhausts kernel
memory by leaking thread keyrings:

	#include 

	int main()
	{
		for (;;)
			keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_THREAD_KEYRING);
	}

Fix it by only creating a new thread keyring if there wasn't one before.
To make things more consistent, make install_thread_keyring_to_cred()
and install_process_keyring_to_cred() both return 0 if the corresponding
keyring is already present.

Fixes: d84f4f992cbd ("CRED: Inaugurate COW credentials")
Signed-off-by: Eric Biggers 
Signed-off-by: David Howells 
Signed-off-by: Jiri Slaby

KEYS: Change the name of the dead type to ".dead" to prevent user access

2017-05-09T06:19:31+00:00

commit c1644fe041ebaf6519f6809146a77c3ead9193af upstream.

This fixes CVE-2017-6951.

Userspace should not be able to do things with the "dead" key type as it
doesn't have some of the helper functions set upon it that the kernel
needs.  Attempting to use it may cause the kernel to crash.

Fix this by changing the name of the type to ".dead" so that it's rejected
up front on userspace syscalls by key_get_type_from_user().

Though this doesn't seem to affect recent kernels, it does affect older
ones, certainly those prior to:

	commit c06cfb08b88dfbe13be44a69ae2fdc3a7c902d81
	Author: David Howells 
	Date:   Tue Sep 16 17:36:06 2014 +0100
	KEYS: Remove key_type::match in favour of overriding default by match_preparse

which went in before 3.18-rc1.

Signed-off-by: David Howells 
Signed-off-by: Jiri Slaby

KEYS: Disallow keyrings beginning with '.' to be joined as session keyrings

2017-05-09T06:19:30+00:00

commit ee8f844e3c5a73b999edf733df1c529d6503ec2f upstream.

This fixes CVE-2016-9604.

Keyrings whose name begin with a '.' are special internal keyrings and so
userspace isn't allowed to create keyrings by this name to prevent
shadowing.  However, the patch that added the guard didn't fix
KEYCTL_JOIN_SESSION_KEYRING.  Not only can that create dot-named keyrings,
it can also subscribe to them as a session keyring if they grant SEARCH
permission to the user.

This, for example, allows a root process to set .builtin_trusted_keys as
its session keyring, at which point it has full access because now the
possessor permissions are added.  This permits root to add extra public
keys, thereby bypassing module verification.

This also affects kexec and IMA.

This can be tested by (as root):

	keyctl session .builtin_trusted_keys
	keyctl add user a a @s
	keyctl list @s

which on my test box gives me:

	2 keys in keyring:
	180010936: ---lswrv     0     0 asymmetric: Build time autogenerated kernel key: ae3d4a31b82daa8e1a75b49dc2bba949fd992a05
	801382539: --alswrv     0     0 user: a


Fix this by rejecting names beginning with a '.' in the keyctl.

Signed-off-by: David Howells 
Acked-by: Mimi Zohar 
cc: linux-ima-devel@lists.sourceforge.net
Signed-off-by: Jiri Slaby

selinux: fix off-by-one in setprocattr

2017-02-16T10:44:42+00:00

commit 0c461cb727d146c9ef2d3e86214f498b78b7d125 upstream.

SELinux tries to support setting/clearing of /proc/pid/attr attributes
from the shell by ignoring terminating newlines and treating an
attribute value that begins with a NUL or newline as an attempt to
clear the attribute.  However, the test for clearing attributes has
always been wrong; it has an off-by-one error, and this could further
lead to reading past the end of the allocated buffer since commit
bb646cdb12e75d82258c2f2e7746d5952d3e321a ("proc_pid_attr_write():
switch to memdup_user()").  Fix the off-by-one error.

Even with this fix, setting and clearing /proc/pid/attr attributes
from the shell is not straightforward since the interface does not
support multiple write() calls (so shells that write the value and
newline separately will set and then immediately clear the attribute,
requiring use of echo -n to set the attribute), whereas trying to use
echo -n "" to clear the attribute causes the shell to skip the
write() call altogether since POSIX says that a zero-length write
causes no side effects. Thus, one must use echo -n to set and echo
without -n to clear, as in the following example:
$ echo -n unconfined_u:object_r:user_home_t:s0 > /proc/$$/attr/fscreate
$ cat /proc/$$/attr/fscreate
unconfined_u:object_r:user_home_t:s0
$ echo "" > /proc/$$/attr/fscreate
$ cat /proc/$$/attr/fscreate

Note the use of /proc/$$ rather than /proc/self, as otherwise
the cat command will read its own attribute value, not that of the shell.

There are no users of this facility to my knowledge; possibly we
should just get rid of it.

UPDATE: Upon further investigation it appears that a local process
with the process:setfscreate permission can cause a kernel panic as a
result of this bug.  This patch fixes CVE-2017-2618.

Signed-off-by: Stephen Smalley 
[PM: added the update about CVE-2017-2618 to the commit description]
Signed-off-by: Paul Moore 
Signed-off-by: Jiri Slaby 

Signed-off-by: James Morris

apparmor: do not expose kernel stack

2017-01-27T10:16:15+00:00

commit f4ee2def2d70692ccff0d55353df4ee594fd0017 upstream.

Do not copy uninitalized fields th.td_hilen, th.td_data.

Signed-off-by: Heinrich Schuchardt 
Signed-off-by: John Johansen 
Signed-off-by: Jiri Slaby

apparmor: fix module parameters can be changed after policy is locked

2017-01-27T10:16:15+00:00

commit 58acf9d911c8831156634a44d0b022d683e1e50c upstream.

the policy_lock parameter is a one way switch that prevents policy
from being further modified. Unfortunately some of the module parameters
can effectively modify policy by turning off enforcement.

split policy_admin_capable into a view check and a full admin check,
and update the admin check to test the policy_lock parameter.

Signed-off-by: John Johansen 
Signed-off-by: Jiri Slaby

apparmor: fix oops in profile_unpack() when policy_db is not present

2017-01-27T10:16:14+00:00

commit 5f20fdfed16bc599a325a145bf0123a8e1c9beea upstream.

BugLink: http://bugs.launchpad.net/bugs/1592547

If unpack_dfa() returns NULL due to the dfa not being present,
profile_unpack() is not checking if the dfa is not present (NULL).

Signed-off-by: John Johansen 
Signed-off-by: Jiri Slaby

apparmor: don't check for vmalloc_addr if kvzalloc() failed

2017-01-27T10:16:13+00:00

commit 3197f5adf539a3ee6331f433a51483f8c842f890 upstream.

Signed-off-by: John Johansen 
Signed-off-by: Jiri Slaby

apparmor: add missing id bounds check on dfa verification

2017-01-27T10:16:13+00:00

commit 15756178c6a65b261a080e21af4766f59cafc112 upstream.

Signed-off-by: John Johansen 
Signed-off-by: Jiri Slaby

apparmor: fix refcount race when finding a child profile

2017-01-27T10:16:12+00:00

commit de7c4cc947f9f56f61520ee7edaf380434a98c8d upstream.

When finding a child profile via an rcu critical section, the profile
may be put and scheduled for deletion after the child is found but
before its refcount is incremented.

Protect against this by repeating the lookup if the profiles refcount
is 0 and is one its way to deletion.

Signed-off-by: John Johansen 
Acked-by: Seth Arnold 
Signed-off-by: Jiri Slaby