<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/security/keys, branch v3.19</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v3.19</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v3.19'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2015-01-05T15:58:01Z</updated>
<entry>
<title>KEYS: close race between key lookup and freeing</title>
<updated>2015-01-05T15:58:01Z</updated>
<author>
<name>Sasha Levin</name>
<email>sasha.levin@oracle.com</email>
</author>
<published>2014-12-29T14:39:01Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a3a8784454692dd72e5d5d34dcdab17b4420e74c'/>
<id>urn:sha1:a3a8784454692dd72e5d5d34dcdab17b4420e74c</id>
<content type='text'>
When a key is being garbage collected, it's key-&gt;user would get put before
the -&gt;destroy() callback is called, where the key is removed from it's
respective tracking structures.

This leaves a key hanging in a semi-invalid state which leaves a window open
for a different task to try an access key-&gt;user. An example is
find_keyring_by_name() which would dereference key-&gt;user for a key that is
in the process of being garbage collected (where key-&gt;user was freed but
-&gt;destroy() wasn't called yet - so it's still present in the linked list).

This would cause either a panic, or corrupt memory.

Fixes CVE-2014-9529.

Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</content>
</entry>
<entry>
<title>KEYS: remove a bogus NULL check</title>
<updated>2014-12-16T07:05:20Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2014-12-11T19:59:38Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=5057975ae38452679b964f1382c5efcb9faee74e'/>
<id>urn:sha1:5057975ae38452679b964f1382c5efcb9faee74e</id>
<content type='text'>
We already checked if "desc" was NULL at the beginning of the function
and we've dereferenced it so this causes a static checker warning.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: James Morris &lt;james.l.morris@oracle.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity into for-linus</title>
<updated>2014-12-16T01:49:10Z</updated>
<author>
<name>James Morris</name>
<email>james.l.morris@oracle.com</email>
</author>
<published>2014-12-16T01:49:10Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d0bffab0439fb7edaee09677b636eef5991e8b80'/>
<id>urn:sha1:d0bffab0439fb7edaee09677b636eef5991e8b80</id>
<content type='text'>
</content>
</entry>
<entry>
<title>KEYS: Fix stale key registration at error path</title>
<updated>2014-12-07T02:50:36Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2014-12-04T17:25:19Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b26bdde5bb27f3f900e25a95e33a0c476c8c2c48'/>
<id>urn:sha1:b26bdde5bb27f3f900e25a95e33a0c476c8c2c48</id>
<content type='text'>
When loading encrypted-keys module, if the last check of
aes_get_sizes() in init_encrypted() fails, the driver just returns an
error without unregistering its key type.  This results in the stale
entry in the list.  In addition to memory leaks, this leads to a kernel
crash when registering a new key type later.

This patch fixes the problem by swapping the calls of aes_get_sizes()
and register_key_type(), and releasing resources properly at the error
paths.

Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=908163
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>KEYS: request_key() should reget expired keys rather than give EKEYEXPIRED</title>
<updated>2014-12-01T22:52:53Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2014-12-01T22:52:53Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=0b0a84154eff56913e91df29de5c3a03a0029e38'/>
<id>urn:sha1:0b0a84154eff56913e91df29de5c3a03a0029e38</id>
<content type='text'>
Since the keyring facility can be viewed as a cache (at least in some
applications), the local expiration time on the key should probably be viewed
as a 'needs updating after this time' property rather than an absolute 'anyone
now wanting to use this object is out of luck' property.

Since request_key() is the main interface for the usage of keys, this should
update or replace an expired key rather than issuing EKEYEXPIRED if the local
expiration has been reached (ie. it should refresh the cache).

For absolute conditions where refreshing the cache probably doesn't help, the
key can be negatively instantiated using KEYCTL_REJECT_KEY with EKEYEXPIRED
given as the error to issue.  This will still cause request_key() to return
EKEYEXPIRED as that was explicitly set.

In the future, if the key type has an update op available, we might want to
upcall with the expired key and allow the upcall to update it.  We would pass
a different operation name (the first column in /etc/request-key.conf) to the
request-key program.

request_key() returning EKEYEXPIRED is causing an NFS problem which Chuck
Lever describes thusly:

	After about 10 minutes, my NFSv4 functional tests fail because the
	ownership of the test files goes to "-2". Looking at /proc/keys
	shows that the id_resolv keys that map to my test user ID have
	expired. The ownership problem persists until the expired keys are
	purged from the keyring, and fresh keys are obtained.

	I bisected the problem to 3.13 commit b2a4df200d57 ("KEYS: Expand
	the capacity of a keyring"). This commit inadvertantly changes the
	API contract of the internal function keyring_search_aux().

	The root cause appears to be that b2a4df200d57 made "no state check"
	the default behavior. "No state check" means the keyring search
	iterator function skips checking the key's expiry timeout, and
	returns expired keys.  request_key_and_link() depends on getting
	an -EAGAIN result code to know when to perform an upcall to refresh
	an expired key.

This patch can be tested directly by:

	keyctl request2 user debug:fred a @s
	keyctl timeout %user:debug:fred 3
	sleep 4
	keyctl request2 user debug:fred a @s

Without the patch, the last command gives error EKEYEXPIRED, but with the
command it gives a new key.

Reported-by: Carl Hetherington &lt;cth@carlh.net&gt;
Reported-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Tested-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
</content>
</entry>
<entry>
<title>KEYS: Simplify KEYRING_SEARCH_{NO,DO}_STATE_CHECK flags</title>
<updated>2014-12-01T22:52:50Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2014-12-01T22:52:50Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=054f6180d8b5602b431b5924976c956e760488b1'/>
<id>urn:sha1:054f6180d8b5602b431b5924976c956e760488b1</id>
<content type='text'>
Simplify KEYRING_SEARCH_{NO,DO}_STATE_CHECK flags to be two variations of the
same flag.  They are effectively mutually exclusive and one or the other
should be provided, but not both.

Keyring cycle detection and key possession determination are the only things
that set NO_STATE_CHECK, except that neither flag really does anything there
because neither purpose makes use of the keyring_search_iterator() function,
but rather provides their own.

For cycle detection we definitely want to check inside of expired keyrings,
just so that we don't create a cycle we can't get rid of.  Revoked keyrings
are cleared at revocation time and can't then be reused, so shouldn't be a
problem either way.

For possession determination, we *might* want to validate each keyring before
searching it: do you possess a key that's hidden behind an expired or just
plain inaccessible keyring?  Currently, the answer is yes.  Note that you
cannot, however, possess a key behind a revoked keyring because they are
cleared on revocation.

keyring_search() sets DO_STATE_CHECK, which is correct.

request_key_and_link() currently doesn't specify whether to check the key
state or not - but it should set DO_STATE_CHECK.

key_get_instantiation_authkey() also currently doesn't specify whether to
check the key state or not - but it probably should also set DO_STATE_CHECK.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Tested-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
</content>
</entry>
<entry>
<title>KEYS: Fix the size of the key description passed to/from userspace</title>
<updated>2014-12-01T22:52:45Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2014-12-01T22:52:45Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=aa9d4437893f7e015ce5b6d6c443a9ba92c8a2e7'/>
<id>urn:sha1:aa9d4437893f7e015ce5b6d6c443a9ba92c8a2e7</id>
<content type='text'>
When a key description argument is imported into the kernel from userspace, as
happens in add_key(), request_key(), KEYCTL_JOIN_SESSION_KEYRING,
KEYCTL_SEARCH, the description is copied into a buffer up to PAGE_SIZE in size.
PAGE_SIZE, however, is a variable quantity, depending on the arch.  Fix this at
4096 instead (ie. 4095 plus a NUL termination) and define a constant
(KEY_MAX_DESC_SIZE) to this end.

When reading the description back with KEYCTL_DESCRIBE, a PAGE_SIZE internal
buffer is allocated into which the information and description will be
rendered.  This means that the description will get truncated if an extremely
long description it has to be crammed into the buffer with the stringified
information.  There is no particular need to copy the description into the
buffer, so just copy it directly to userspace in a separate operation.

Reported-by: Christian Kastner &lt;debian@kvr.at&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Tested-by: Christian Kastner &lt;debian@kvr.at&gt;
</content>
</entry>
<entry>
<title>Merge commit 'v3.17' into next</title>
<updated>2014-11-19T10:32:12Z</updated>
<author>
<name>James Morris</name>
<email>james.l.morris@oracle.com</email>
</author>
<published>2014-11-19T10:32:12Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b10778a00d40b3d9fdaaf5891e802794781ff71c'/>
<id>urn:sha1:b10778a00d40b3d9fdaaf5891e802794781ff71c</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security</title>
<updated>2014-10-12T14:13:55Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-10-12T14:13:55Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=5e40d331bd72447197f26525f21711c4a265b6a6'/>
<id>urn:sha1:5e40d331bd72447197f26525f21711c4a265b6a6</id>
<content type='text'>
Pull security subsystem updates from James Morris.

Mostly ima, selinux, smack and key handling updates.

* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (65 commits)
  integrity: do zero padding of the key id
  KEYS: output last portion of fingerprint in /proc/keys
  KEYS: strip 'id:' from ca_keyid
  KEYS: use swapped SKID for performing partial matching
  KEYS: Restore partial ID matching functionality for asymmetric keys
  X.509: If available, use the raw subjKeyId to form the key description
  KEYS: handle error code encoded in pointer
  selinux: normalize audit log formatting
  selinux: cleanup error reporting in selinux_nlmsg_perm()
  KEYS: Check hex2bin()'s return when generating an asymmetric key ID
  ima: detect violations for mmaped files
  ima: fix race condition on ima_rdwr_violation_check and process_measurement
  ima: added ima_policy_flag variable
  ima: return an error code from ima_add_boot_aggregate()
  ima: provide 'ima_appraise=log' kernel option
  ima: move keyring initialization to ima_init()
  PKCS#7: Handle PKCS#7 messages that contain no X.509 certs
  PKCS#7: Better handling of unsupported crypto
  KEYS: Overhaul key identification when searching for asymmetric keys
  KEYS: Implement binary asymmetric key ID handling
  ...
</content>
</entry>
<entry>
<title>KEYS: Make the key matching functions return bool</title>
<updated>2014-09-16T16:36:08Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2014-09-16T16:36:08Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=0c903ab64feb0fe83eac9f67a06e2f5b9508de16'/>
<id>urn:sha1:0c903ab64feb0fe83eac9f67a06e2f5b9508de16</id>
<content type='text'>
Make the key matching functions pointed to by key_match_data::cmp return bool
rather than int.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: Vivek Goyal &lt;vgoyal@redhat.com&gt;
</content>
</entry>
</feed>
