<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/security, branch v3.14</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/security?h=v3.14</id>
<link rel='self' href='https://git.amat.us/linux/atom/security?h=v3.14'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2014-03-18T16:42:33Z</updated>
<entry>
<title>Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec</title>
<updated>2014-03-18T16:42:33Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2014-03-18T16:42:33Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=72c2dfdefa42c747c8e61f3d3ebfafc8e8d5762f'/>
<id>urn:sha1:72c2dfdefa42c747c8e61f3d3ebfafc8e8d5762f</id>
<content type='text'>
Steffen Klassert says:

====================
1) Fix a sleep in atomic when pfkey_sadb2xfrm_user_sec_ctx()
   is called from pfkey_compile_policy().
   Fix from Nikolay Aleksandrov.

2) security_xfrm_policy_alloc() can be called in process and atomic
   context. Add an argument to let the callers choose the appropriate
   way. Fix from Nikolay Aleksandrov.
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>selinux: add gfp argument to security_xfrm_policy_alloc and fix callers</title>
<updated>2014-03-10T07:30:02Z</updated>
<author>
<name>Nikolay Aleksandrov</name>
<email>nikolay@redhat.com</email>
</author>
<published>2014-03-07T11:44:19Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=52a4c6404f91f2d2c5592ee6365a8418c4565f53'/>
<id>urn:sha1:52a4c6404f91f2d2c5592ee6365a8418c4565f53</id>
<content type='text'>
security_xfrm_policy_alloc can be called in atomic context so the
allocation should be done with GFP_ATOMIC. Add an argument to let the
callers choose the appropriate way. In order to do so a gfp argument
needs to be added to the method xfrm_policy_alloc_security in struct
security_operations and to the internal function
selinux_xfrm_alloc_user. After that switch to GFP_ATOMIC in the atomic
callers and leave GFP_KERNEL as before for the rest.
The path that needed the gfp argument addition is:
security_xfrm_policy_alloc -&gt; security_ops.xfrm_policy_alloc_security -&gt;
all users of xfrm_policy_alloc_security (e.g. selinux_xfrm_policy_alloc) -&gt;
selinux_xfrm_alloc_user (here the allocation used to be GFP_KERNEL only)

Now adding a gfp argument to selinux_xfrm_alloc_user requires us to also
add it to security_context_to_sid which is used inside and prior to this
patch did only GFP_KERNEL allocation. So add gfp argument to
security_context_to_sid and adjust all of its callers as well.

CC: Paul Moore &lt;paul@paul-moore.com&gt;
CC: Dave Jones &lt;davej@redhat.com&gt;
CC: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
CC: Fan Du &lt;fan.du@windriver.com&gt;
CC: David S. Miller &lt;davem@davemloft.net&gt;
CC: LSM list &lt;linux-security-module@vger.kernel.org&gt;
CC: SELinux list &lt;selinux@tycho.nsa.gov&gt;

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@redhat.com&gt;
Acked-by: Paul Moore &lt;paul@paul-moore.com&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
</content>
</entry>
<entry>
<title>KEYS: Make the keyring cycle detector ignore other keyrings of the same name</title>
<updated>2014-03-10T01:57:18Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2014-03-09T08:21:58Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=979e0d74651ba5aa533277f2a6423d0f982fb6f6'/>
<id>urn:sha1:979e0d74651ba5aa533277f2a6423d0f982fb6f6</id>
<content type='text'>
This fixes CVE-2014-0102.

The following command sequence produces an oops:

	keyctl new_session
	i=`keyctl newring _ses @s`
	keyctl link @s $i

The problem is that search_nested_keyrings() sees two keyrings that have
matching type and description, so keyring_compare_object() returns true.
s_n_k() then passes the key to the iterator function -
keyring_detect_cycle_iterator() - which *should* check to see whether this is
the keyring of interest, not just one with the same name.

Because assoc_array_find() will return one and only one match, I assumed that
the iterator function would only see an exact match or never be called - but
the iterator isn't only called from assoc_array_find()...

The oops looks something like this:

	kernel BUG at /data/fs/linux-2.6-fscache/security/keys/keyring.c:1003!
	invalid opcode: 0000 [#1] SMP
	...
	RIP: keyring_detect_cycle_iterator+0xe/0x1f
	...
	Call Trace:
	  search_nested_keyrings+0x76/0x2aa
	  __key_link_check_live_key+0x50/0x5f
	  key_link+0x4e/0x85
	  keyctl_keyring_link+0x60/0x81
	  SyS_keyctl+0x65/0xe4
	  tracesys+0xdd/0xe2

The fix is to make keyring_detect_cycle_iterator() check that the key it
has is the key it was actually looking for rather than calling BUG_ON().

A testcase has been included in the keyutils testsuite for this:

	http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=891f3365d07f1996778ade0e3428f01878a1790b

Reported-by: Tommi Rantala &lt;tt.rantala@gmail.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: James Morris &lt;james.l.morris@oracle.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'stable-3.14' of git://git.infradead.org/users/pcmoore/selinux into for-linus</title>
<updated>2014-02-24T03:40:16Z</updated>
<author>
<name>James Morris</name>
<email>james.l.morris@oracle.com</email>
</author>
<published>2014-02-24T03:40:16Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e4e027ea2d7a59819a0384c2d1031aafc5833903'/>
<id>urn:sha1:e4e027ea2d7a59819a0384c2d1031aafc5833903</id>
<content type='text'>
</content>
</entry>
<entry>
<title>SELinux: bigendian problems with filename trans rules</title>
<updated>2014-02-20T17:07:58Z</updated>
<author>
<name>Eric Paris</name>
<email>eparis@redhat.com</email>
</author>
<published>2014-02-20T15:56:45Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=9085a6422900092886da8c404e1c5340c4ff1cbf'/>
<id>urn:sha1:9085a6422900092886da8c404e1c5340c4ff1cbf</id>
<content type='text'>
When writing policy via /sys/fs/selinux/policy I wrote the type and class
of filename trans rules in CPU endian instead of little endian.  On
x86_64 this works just fine, but it means that on big endian arch's like
ppc64 and s390 userspace reads the policy and converts it from
le32_to_cpu.  So the values are all screwed up.  Write the values in le
format like it should have been to start.

Signed-off-by: Eric Paris &lt;eparis@redhat.com&gt;
Acked-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>
<entry>
<title>Merge branch 'stable-3.14' of git://git.infradead.org/users/pcmoore/selinux into for-linus</title>
<updated>2014-02-10T00:48:21Z</updated>
<author>
<name>James Morris</name>
<email>james.l.morris@oracle.com</email>
</author>
<published>2014-02-10T00:48:21Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f743166da7e93b617dd93120cdb5edcc8b84c464'/>
<id>urn:sha1:f743166da7e93b617dd93120cdb5edcc8b84c464</id>
<content type='text'>
</content>
</entry>
<entry>
<title>SELinux:  Fix kernel BUG on empty security contexts.</title>
<updated>2014-02-05T17:20:51Z</updated>
<author>
<name>Stephen Smalley</name>
<email>sds@tycho.nsa.gov</email>
</author>
<published>2014-01-30T16:26:59Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2172fa709ab32ca60e86179dc67d0857be8e2c98'/>
<id>urn:sha1:2172fa709ab32ca60e86179dc67d0857be8e2c98</id>
<content type='text'>
Setting an empty security context (length=0) on a file will
lead to incorrectly dereferencing the type and other fields
of the security context structure, yielding a kernel BUG.
As a zero-length security context is never valid, just reject
all such security contexts whether coming from userspace
via setxattr or coming from the filesystem upon a getxattr
request by SELinux.

Setting a security context value (empty or otherwise) unknown to
SELinux in the first place is only possible for a root process
(CAP_MAC_ADMIN), and, if running SELinux in enforcing mode, only
if the corresponding SELinux mac_admin permission is also granted
to the domain by policy.  In Fedora policies, this is only allowed for
specific domains such as livecd for setting down security contexts
that are not defined in the build host policy.

Reproducer:
su
setenforce 0
touch foo
setfattr -n security.selinux foo

Caveat:
Relabeling or removing foo after doing the above may not be possible
without booting with SELinux disabled.  Any subsequent access to foo
after doing the above will also trigger the BUG.

BUG output from Matthew Thode:
[  473.893141] ------------[ cut here ]------------
[  473.962110] kernel BUG at security/selinux/ss/services.c:654!
[  473.995314] invalid opcode: 0000 [#6] SMP
[  474.027196] Modules linked in:
[  474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G      D   I
3.13.0-grsec #1
[  474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
07/29/10
[  474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
ffff8805f50cd488
[  474.183707] RIP: 0010:[&lt;ffffffff814681c7&gt;]  [&lt;ffffffff814681c7&gt;]
context_struct_compute_av+0xce/0x308
[  474.219954] RSP: 0018:ffff8805c0ac3c38  EFLAGS: 00010246
[  474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
0000000000000100
[  474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
ffff8805e8aaa000
[  474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
0000000000000006
[  474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
0000000000000006
[  474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
0000000000000000
[  474.453816] FS:  00007f2e75220800(0000) GS:ffff88061fc00000(0000)
knlGS:0000000000000000
[  474.489254] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
00000000000207f0
[  474.556058] Stack:
[  474.584325]  ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
ffff8805f1190a40
[  474.618913]  ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
ffff8805e8aac860
[  474.653955]  ffff8805c0ac3cb8 000700068113833a ffff880606c75060
ffff8805c0ac3d94
[  474.690461] Call Trace:
[  474.723779]  [&lt;ffffffff811b549b&gt;] ? lookup_fast+0x1cd/0x22a
[  474.778049]  [&lt;ffffffff81468824&gt;] security_compute_av+0xf4/0x20b
[  474.811398]  [&lt;ffffffff8196f419&gt;] avc_compute_av+0x2a/0x179
[  474.843813]  [&lt;ffffffff8145727b&gt;] avc_has_perm+0x45/0xf4
[  474.875694]  [&lt;ffffffff81457d0e&gt;] inode_has_perm+0x2a/0x31
[  474.907370]  [&lt;ffffffff81457e76&gt;] selinux_inode_getattr+0x3c/0x3e
[  474.938726]  [&lt;ffffffff81455cf6&gt;] security_inode_getattr+0x1b/0x22
[  474.970036]  [&lt;ffffffff811b057d&gt;] vfs_getattr+0x19/0x2d
[  475.000618]  [&lt;ffffffff811b05e5&gt;] vfs_fstatat+0x54/0x91
[  475.030402]  [&lt;ffffffff811b063b&gt;] vfs_lstat+0x19/0x1b
[  475.061097]  [&lt;ffffffff811b077e&gt;] SyS_newlstat+0x15/0x30
[  475.094595]  [&lt;ffffffff8113c5c1&gt;] ? __audit_syscall_entry+0xa1/0xc3
[  475.148405]  [&lt;ffffffff8197791e&gt;] system_call_fastpath+0x16/0x1b
[  475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
75 02 &lt;0f&gt; 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
[  475.255884] RIP  [&lt;ffffffff814681c7&gt;]
context_struct_compute_av+0xce/0x308
[  475.296120]  RSP &lt;ffff8805c0ac3c38&gt;
[  475.328734] ---[ end trace f076482e9d754adc ]---

Reported-by:  Matthew Thode &lt;mthode@mthode.org&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>
<entry>
<title>selinux: add SOCK_DIAG_BY_FAMILY to the list of netlink message types</title>
<updated>2014-02-05T17:20:48Z</updated>
<author>
<name>Paul Moore</name>
<email>pmoore@redhat.com</email>
</author>
<published>2014-01-28T19:45:41Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6a96e15096da6e7491107321cfa660c7c2aa119d'/>
<id>urn:sha1:6a96e15096da6e7491107321cfa660c7c2aa119d</id>
<content type='text'>
The SELinux AF_NETLINK/NETLINK_SOCK_DIAG socket class was missing the
SOCK_DIAG_BY_FAMILY definition which caused SELINUX_ERR messages when
the ss tool was run.

 # ss
 Netid  State  Recv-Q Send-Q  Local Address:Port   Peer Address:Port
 u_str  ESTAB  0      0                  * 14189             * 14190
 u_str  ESTAB  0      0                  * 14145             * 14144
 u_str  ESTAB  0      0                  * 14151             * 14150
 {...}
 # ausearch -m SELINUX_ERR
 ----
 time-&gt;Thu Jan 23 11:11:16 2014
 type=SYSCALL msg=audit(1390493476.445:374):
  arch=c000003e syscall=44 success=yes exit=40
  a0=3 a1=7fff03aa11f0 a2=28 a3=0 items=0 ppid=1852 pid=1895
  auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
  tty=pts0 ses=1 comm="ss" exe="/usr/sbin/ss"
  subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
 type=SELINUX_ERR msg=audit(1390493476.445:374):
  SELinux:  unrecognized netlink message type=20 for sclass=32

Signed-off-by: Paul Moore &lt;pmoore@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'v3.13' into stable-3.14</title>
<updated>2014-02-05T15:39:48Z</updated>
<author>
<name>Paul Moore</name>
<email>pmoore@redhat.com</email>
</author>
<published>2014-01-28T19:44:16Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=825e587af2e90e9b953849f3347a01d8f383d577'/>
<id>urn:sha1:825e587af2e90e9b953849f3347a01d8f383d577</id>
<content type='text'>
Linux 3.13

Conflicts:
	security/selinux/hooks.c

Trivial merge issue in selinux_inet_conn_request() likely due to me
including patches that I sent to the stable folks in my next tree
resulting in the patch hitting twice (I think).  Thankfully it was an
easy fix this time, but regardless, lesson learned, I will not do that
again.
</content>
</entry>
<entry>
<title>security: select correct default LSM_MMAP_MIN_ADDR on arm on arm64</title>
<updated>2014-02-05T14:59:14Z</updated>
<author>
<name>Colin Cross</name>
<email>ccross@android.com</email>
</author>
<published>2014-02-04T02:15:32Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=530b099dfe8499d639e7fbcad28c4199e2a720c7'/>
<id>urn:sha1:530b099dfe8499d639e7fbcad28c4199e2a720c7</id>
<content type='text'>
Binaries compiled for arm may run on arm64 if CONFIG_COMPAT is
selected.  Set LSM_MMAP_MIN_ADDR to 32768 if ARM64 &amp;&amp; COMPAT to
prevent selinux failures launching 32-bit static executables that
are mapped at 0x8000.

Signed-off-by: Colin Cross &lt;ccross@android.com&gt;
Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Acked-by: Eric Paris &lt;eparis@redhat.com&gt;
Acked-by: James Morris &lt;james.l.morris@oracle.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
</entry>
</feed>
