<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/security, branch v3.18</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.18</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v3.18'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2014-12-01T22:52:53Z</updated>
<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 branch 'stable-3.18' of git://git.infradead.org/users/pcmoore/selinux into for-linus</title>
<updated>2014-11-13T10:49:53Z</updated>
<author>
<name>James Morris</name>
<email>james.l.morris@oracle.com</email>
</author>
<published>2014-11-13T10:49:53Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=09c626892772e6fe03f768b3492fbb126f465fe6'/>
<id>urn:sha1:09c626892772e6fe03f768b3492fbb126f465fe6</id>
<content type='text'>
</content>
</entry>
<entry>
<title>selinux: convert WARN_ONCE() to printk() in selinux_nlmsg_perm()</title>
<updated>2014-11-12T21:14:02Z</updated>
<author>
<name>Richard Guy Briggs</name>
<email>rgb@redhat.com</email>
</author>
<published>2014-11-12T19:01:34Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d950f84c1c6658faec2ecbf5b09f7e7191953394'/>
<id>urn:sha1:d950f84c1c6658faec2ecbf5b09f7e7191953394</id>
<content type='text'>
Convert WARN_ONCE() to printk() in selinux_nlmsg_perm().

After conversion from audit_log() in commit e173fb26, WARN_ONCE() was
deemed too alarmist, so switch it to printk().

Signed-off-by: Richard Guy Briggs &lt;rgb@redhat.com&gt;
[PM: Changed to printk(WARNING) so we catch all of the different
 invalid netlink messages.  In Richard's defense, he brought this
 point up earlier, but I didn't understand his point at the time.]
Signed-off-by: Paul Moore &lt;pmoore@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity into for-linus</title>
<updated>2014-10-29T04:03:54Z</updated>
<author>
<name>James Morris</name>
<email>james.l.morris@oracle.com</email>
</author>
<published>2014-10-29T04:03:54Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=6c880ad51b829006c5387df88967954c0e874993'/>
<id>urn:sha1:6c880ad51b829006c5387df88967954c0e874993</id>
<content type='text'>
</content>
</entry>
<entry>
<title>evm: check xattr value length and type in evm_inode_setxattr()</title>
<updated>2014-10-28T14:06:31Z</updated>
<author>
<name>Dmitry Kasatkin</name>
<email>d.kasatkin@samsung.com</email>
</author>
<published>2014-10-28T12:28:49Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=3b1deef6b1289a99505858a3b212c5b50adf0c2f'/>
<id>urn:sha1:3b1deef6b1289a99505858a3b212c5b50adf0c2f</id>
<content type='text'>
evm_inode_setxattr() can be called with no value. The function does not
check the length so that following command can be used to produce the
kernel oops: setfattr -n security.evm FOO. This patch fixes it.

Changes in v3:
* there is no reason to return different error codes for EVM_XATTR_HMAC
  and non EVM_XATTR_HMAC. Remove unnecessary test then.

Changes in v2:
* testing for validity of xattr type

[ 1106.396921] BUG: unable to handle kernel NULL pointer dereference at           (null)
[ 1106.398192] IP: [&lt;ffffffff812af7b8&gt;] evm_inode_setxattr+0x2a/0x48
[ 1106.399244] PGD 29048067 PUD 290d7067 PMD 0
[ 1106.399953] Oops: 0000 [#1] SMP
[ 1106.400020] Modules linked in: bridge stp llc evdev serio_raw i2c_piix4 button fuse
[ 1106.400020] CPU: 0 PID: 3635 Comm: setxattr Not tainted 3.16.0-kds+ #2936
[ 1106.400020] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 1106.400020] task: ffff8800291a0000 ti: ffff88002917c000 task.ti: ffff88002917c000
[ 1106.400020] RIP: 0010:[&lt;ffffffff812af7b8&gt;]  [&lt;ffffffff812af7b8&gt;] evm_inode_setxattr+0x2a/0x48
[ 1106.400020] RSP: 0018:ffff88002917fd50  EFLAGS: 00010246
[ 1106.400020] RAX: 0000000000000000 RBX: ffff88002917fdf8 RCX: 0000000000000000
[ 1106.400020] RDX: 0000000000000000 RSI: ffffffff818136d3 RDI: ffff88002917fdf8
[ 1106.400020] RBP: ffff88002917fd68 R08: 0000000000000000 R09: 00000000003ec1df
[ 1106.400020] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800438a0a00
[ 1106.400020] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 1106.400020] FS:  00007f7dfa7d7740(0000) GS:ffff88005da00000(0000) knlGS:0000000000000000
[ 1106.400020] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1106.400020] CR2: 0000000000000000 CR3: 000000003763e000 CR4: 00000000000006f0
[ 1106.400020] Stack:
[ 1106.400020]  ffff8800438a0a00 ffff88002917fdf8 0000000000000000 ffff88002917fd98
[ 1106.400020]  ffffffff812a1030 ffff8800438a0a00 ffff88002917fdf8 0000000000000000
[ 1106.400020]  0000000000000000 ffff88002917fde0 ffffffff8116d08a ffff88002917fdc8
[ 1106.400020] Call Trace:
[ 1106.400020]  [&lt;ffffffff812a1030&gt;] security_inode_setxattr+0x5d/0x6a
[ 1106.400020]  [&lt;ffffffff8116d08a&gt;] vfs_setxattr+0x6b/0x9f
[ 1106.400020]  [&lt;ffffffff8116d1e0&gt;] setxattr+0x122/0x16c
[ 1106.400020]  [&lt;ffffffff811687e8&gt;] ? mnt_want_write+0x21/0x45
[ 1106.400020]  [&lt;ffffffff8114d011&gt;] ? __sb_start_write+0x10f/0x143
[ 1106.400020]  [&lt;ffffffff811687e8&gt;] ? mnt_want_write+0x21/0x45
[ 1106.400020]  [&lt;ffffffff811687c0&gt;] ? __mnt_want_write+0x48/0x4f
[ 1106.400020]  [&lt;ffffffff8116d3e6&gt;] SyS_setxattr+0x6e/0xb0
[ 1106.400020]  [&lt;ffffffff81529da9&gt;] system_call_fastpath+0x16/0x1b
[ 1106.400020] Code: c3 0f 1f 44 00 00 55 48 89 e5 41 55 49 89 d5 41 54 49 89 fc 53 48 89 f3 48 c7 c6 d3 36 81 81 48 89 df e8 18 22 04 00 85 c0 75 07 &lt;41&gt; 80 7d 00 02 74 0d 48 89 de 4c 89 e7 e8 5a fe ff ff eb 03 83
[ 1106.400020] RIP  [&lt;ffffffff812af7b8&gt;] evm_inode_setxattr+0x2a/0x48
[ 1106.400020]  RSP &lt;ffff88002917fd50&gt;
[ 1106.400020] CR2: 0000000000000000
[ 1106.428061] ---[ end trace ae08331628ba3050 ]---

Reported-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Dmitry Kasatkin &lt;d.kasatkin@samsung.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>ima: check xattr value length and type in the ima_inode_setxattr()</title>
<updated>2014-10-28T14:03:49Z</updated>
<author>
<name>Dmitry Kasatkin</name>
<email>d.kasatkin@samsung.com</email>
</author>
<published>2014-10-28T11:31:22Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a48fda9de94500a3152a56b723d0a64ae236547c'/>
<id>urn:sha1:a48fda9de94500a3152a56b723d0a64ae236547c</id>
<content type='text'>
ima_inode_setxattr() can be called with no value. Function does not
check the length so that following command can be used to produce
kernel oops: setfattr -n security.ima FOO. This patch fixes it.

Changes in v3:
* for stable reverted "allow setting hash only in fix or log mode"
  It will be a separate patch.

Changes in v2:
* testing validity of xattr type
* allow setting hash only in fix or log mode (Mimi)

[  261.562522] BUG: unable to handle kernel NULL pointer dereference at           (null)
[  261.564109] IP: [&lt;ffffffff812af272&gt;] ima_inode_setxattr+0x3e/0x5a
[  261.564109] PGD 3112f067 PUD 42965067 PMD 0
[  261.564109] Oops: 0000 [#1] SMP
[  261.564109] Modules linked in: bridge stp llc evdev serio_raw i2c_piix4 button fuse
[  261.564109] CPU: 0 PID: 3299 Comm: setxattr Not tainted 3.16.0-kds+ #2924
[  261.564109] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  261.564109] task: ffff8800428c2430 ti: ffff880042be0000 task.ti: ffff880042be0000
[  261.564109] RIP: 0010:[&lt;ffffffff812af272&gt;]  [&lt;ffffffff812af272&gt;] ima_inode_setxattr+0x3e/0x5a
[  261.564109] RSP: 0018:ffff880042be3d50  EFLAGS: 00010246
[  261.564109] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000015
[  261.564109] RDX: 0000001500000000 RSI: 0000000000000000 RDI: ffff8800375cc600
[  261.564109] RBP: ffff880042be3d68 R08: 0000000000000000 R09: 00000000004d6256
[  261.564109] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88002149ba00
[  261.564109] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[  261.564109] FS:  00007f6c1e219740(0000) GS:ffff88005da00000(0000) knlGS:0000000000000000
[  261.564109] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  261.564109] CR2: 0000000000000000 CR3: 000000003b35a000 CR4: 00000000000006f0
[  261.564109] Stack:
[  261.564109]  ffff88002149ba00 ffff880042be3df8 0000000000000000 ffff880042be3d98
[  261.564109]  ffffffff812a101b ffff88002149ba00 ffff880042be3df8 0000000000000000
[  261.564109]  0000000000000000 ffff880042be3de0 ffffffff8116d08a ffff880042be3dc8
[  261.564109] Call Trace:
[  261.564109]  [&lt;ffffffff812a101b&gt;] security_inode_setxattr+0x48/0x6a
[  261.564109]  [&lt;ffffffff8116d08a&gt;] vfs_setxattr+0x6b/0x9f
[  261.564109]  [&lt;ffffffff8116d1e0&gt;] setxattr+0x122/0x16c
[  261.564109]  [&lt;ffffffff811687e8&gt;] ? mnt_want_write+0x21/0x45
[  261.564109]  [&lt;ffffffff8114d011&gt;] ? __sb_start_write+0x10f/0x143
[  261.564109]  [&lt;ffffffff811687e8&gt;] ? mnt_want_write+0x21/0x45
[  261.564109]  [&lt;ffffffff811687c0&gt;] ? __mnt_want_write+0x48/0x4f
[  261.564109]  [&lt;ffffffff8116d3e6&gt;] SyS_setxattr+0x6e/0xb0
[  261.564109]  [&lt;ffffffff81529da9&gt;] system_call_fastpath+0x16/0x1b
[  261.564109] Code: 48 89 f7 48 c7 c6 58 36 81 81 53 31 db e8 73 27 04 00 85 c0 75 28 bf 15 00 00 00 e8 8a a5 d9 ff 84 c0 75 05 83 cb ff eb 15 31 f6 &lt;41&gt; 80 7d 00 03 49 8b 7c 24 68 40 0f 94 c6 e8 e1 f9 ff ff 89 d8
[  261.564109] RIP  [&lt;ffffffff812af272&gt;] ima_inode_setxattr+0x3e/0x5a
[  261.564109]  RSP &lt;ffff880042be3d50&gt;
[  261.564109] CR2: 0000000000000000
[  261.599998] ---[ end trace 39a89a3fc267e652 ]---

Reported-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Dmitry Kasatkin &lt;d.kasatkin@samsung.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'stable-3.18' of git://git.infradead.org/users/pcmoore/selinux into for-linus2</title>
<updated>2014-10-16T10:04:18Z</updated>
<author>
<name>James Morris</name>
<email>james.l.morris@oracle.com</email>
</author>
<published>2014-10-16T10:04:18Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=9b32011acdc4428474b7cba865f713a11b9b9bd3'/>
<id>urn:sha1:9b32011acdc4428474b7cba865f713a11b9b9bd3</id>
<content type='text'>
</content>
</entry>
<entry>
<title>selinux: fix inode security list corruption</title>
<updated>2014-10-15T14:37:02Z</updated>
<author>
<name>Stephen Smalley</name>
<email>sds@tycho.nsa.gov</email>
</author>
<published>2014-10-06T20:32:52Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=923190d32de4428afbea5e5773be86bea60a9925'/>
<id>urn:sha1:923190d32de4428afbea5e5773be86bea60a9925</id>
<content type='text'>
sb_finish_set_opts() can race with inode_free_security()
when initializing inode security structures for inodes
created prior to initial policy load or by the filesystem
during -&gt;mount().   This appears to have always been
a possible race, but commit 3dc91d4 ("SELinux:  Fix possible
NULL pointer dereference in selinux_inode_permission()")
made it more evident by immediately reusing the unioned
list/rcu element  of the inode security structure for call_rcu()
upon an inode_free_security().  But the underlying issue
was already present before that commit as a possible use-after-free
of isec.

Shivnandan Kumar reported the list corruption and proposed
a patch to split the list and rcu elements out of the union
as separate fields of the inode_security_struct so that setting
the rcu element would not affect the list element.  However,
this would merely hide the issue and not truly fix the code.

This patch instead moves up the deletion of the list entry
prior to dropping the sbsec-&gt;isec_lock initially.  Then,
if the inode is dropped subsequently, there will be no further
references to the isec.

Reported-by: Shivnandan Kumar &lt;shivnandan.k@samsung.com&gt;
Signed-off-by: Stephen Smalley &lt;sds@tycho.nsa.gov&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Paul Moore &lt;pmoore@redhat.com&gt;
</content>
</entry>
</feed>
