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

selinux: handle TCP SYN-ACK packets correctly in selinux_ip_postroute()

2013-12-20T15:48:59+00:00

commit 446b802437f285de68ffb8d6fac3c44c3cab5b04 upstream.

In selinux_ip_postroute() we perform access checks based on the
packet's security label.  For locally generated traffic we get the
packet's security label from the associated socket; this works in all
cases except for TCP SYN-ACK packets.  In the case of SYN-ACK packet's
the correct security label is stored in the connection's request_sock,
not the server's socket.  Unfortunately, at the point in time when
selinux_ip_postroute() is called we can't query the request_sock
directly, we need to recreate the label using the same logic that
originally labeled the associated request_sock.

See the inline comments for more explanation.

Reported-by: Janak Desai 
Tested-by: Janak Desai 
Signed-off-by: Paul Moore 
Signed-off-by: Greg Kroah-Hartman

selinux: handle TCP SYN-ACK packets correctly in selinux_ip_output()

2013-12-20T15:48:58+00:00

commit 47180068276a04ed31d24fe04c673138208b07a9 upstream.

In selinux_ip_output() we always label packets based on the parent
socket.  While this approach works in almost all cases, it doesn't
work in the case of TCP SYN-ACK packets when the correct label is not
the label of the parent socket, but rather the label of the larval
socket represented by the request_sock struct.

Unfortunately, since the request_sock isn't queued on the parent
socket until *after* the SYN-ACK packet is sent, we can't lookup the
request_sock to determine the correct label for the packet; at this
point in time the best we can do is simply pass/NF_ACCEPT the packet.
It must be said that simply passing the packet without any explicit
labeling action, while far from ideal, is not terrible as the SYN-ACK
packet will inherit any IP option based labeling from the initial
connection request so the label *should* be correct and all our
access controls remain in place so we shouldn't have to worry about
information leaks.

Reported-by: Janak Desai 
Tested-by: Janak Desai 
Signed-off-by: Paul Moore 
Signed-off-by: Greg Kroah-Hartman

selinux: correct locking in selinux_netlbl_socket_connect)

2013-12-04T19:05:40+00:00

commit 42d64e1add3a1ce8a787116036163b8724362145 upstream.

The SELinux/NetLabel glue code has a locking bug that affects systems
with NetLabel enabled, see the kernel error message below.  This patch
corrects this problem by converting the bottom half socket lock to a
more conventional, and correct for this call-path, lock_sock() call.

 ===============================
 [ INFO: suspicious RCU usage. ]
 3.11.0-rc3+ #19 Not tainted
 -------------------------------
 net/ipv4/cipso_ipv4.c:1928 suspicious rcu_dereference_protected() usage!

 other info that might help us debug this:

 rcu_scheduler_active = 1, debug_locks = 0
 2 locks held by ping/731:
  #0:  (slock-AF_INET/1){+.-...}, at: [...] selinux_netlbl_socket_connect
  #1:  (rcu_read_lock){.+.+..}, at: [<...>] netlbl_conn_setattr

 stack backtrace:
 CPU: 1 PID: 731 Comm: ping Not tainted 3.11.0-rc3+ #19
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  0000000000000001 ffff88006f659d28 ffffffff81726b6a ffff88003732c500
  ffff88006f659d58 ffffffff810e4457 ffff88006b845a00 0000000000000000
  000000000000000c ffff880075aa2f50 ffff88006f659d90 ffffffff8169bec7
 Call Trace:
  [] dump_stack+0x54/0x74
  [] lockdep_rcu_suspicious+0xe7/0x120
  [] cipso_v4_sock_setattr+0x187/0x1a0
  [] netlbl_conn_setattr+0x187/0x190
  [] ? netlbl_conn_setattr+0x5/0x190
  [] selinux_netlbl_socket_connect+0xae/0xc0
  [] selinux_socket_connect+0x135/0x170
  [] ? might_fault+0x57/0xb0
  [] security_socket_connect+0x16/0x20
  [] SYSC_connect+0x73/0x130
  [] ? sysret_check+0x22/0x5d
  [] ? trace_hardirqs_on_caller+0xfd/0x1c0
  [] ? trace_hardirqs_on_thunk+0x3a/0x3f
  [] SyS_connect+0xe/0x10
  [] system_call_fastpath+0x16/0x1b

Signed-off-by: Paul Moore 
Signed-off-by: Greg Kroah-Hartman

Revert "ima: policy for RAMFS"

2013-11-29T19:27:58+00:00

commit 08de59eb144d7c41351a467442f898d720f0f15f upstream.

This reverts commit 4c2c392763a682354fac65b6a569adec4e4b5387.

Everything in the initramfs should be measured and appraised,
but until the initramfs has extended attribute support, at
least measured.

Signed-off-by: Mimi Zohar 
Signed-off-by: Greg Kroah-Hartman

apparmor: fix bad lock balance when introspecting policy

2013-10-16T00:54:01+00:00

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

The profile introspection seq file has a locking bug when policy is viewed
from a virtual root (task in a policy namespace), introspection from the
real root is not affected.

The test for root
    while (parent) {
is correct for the real root, but incorrect for tasks in a policy namespace.
This allows the task to walk backup the policy tree past its virtual root
causing it to be unlocked before the virtual root should be in the p_stop
fn.

This results in the following lockdep back trace:
[   78.479744] [ BUG: bad unlock balance detected! ]
[   78.479792] 3.11.0-11-generic #17 Not tainted
[   78.479838] -------------------------------------
[   78.479885] grep/2223 is trying to release lock (&ns->lock) at:
[   78.479952] [] mutex_unlock+0xe/0x10
[   78.480002] but there are no more locks to release!
[   78.480037]
[   78.480037] other info that might help us debug this:
[   78.480037] 1 lock held by grep/2223:
[   78.480037]  #0:  (&p->lock){+.+.+.}, at: [] seq_read+0x3d/0x3d0
[   78.480037]
[   78.480037] stack backtrace:
[   78.480037] CPU: 0 PID: 2223 Comm: grep Not tainted 3.11.0-11-generic #17
[   78.480037] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   78.480037]  ffffffff817bf3be ffff880007763d60 ffffffff817b97ef ffff8800189d2190
[   78.480037]  ffff880007763d88 ffffffff810e1c6e ffff88001f044730 ffff8800189d2190
[   78.480037]  ffffffff817bf3be ffff880007763e00 ffffffff810e5bd6 0000000724fe56b7
[   78.480037] Call Trace:
[   78.480037]  [] ? mutex_unlock+0xe/0x10
[   78.480037]  [] dump_stack+0x54/0x74
[   78.480037]  [] print_unlock_imbalance_bug+0xee/0x100
[   78.480037]  [] ? mutex_unlock+0xe/0x10
[   78.480037]  [] lock_release_non_nested+0x226/0x300
[   78.480037]  [] ? __mutex_unlock_slowpath+0xce/0x180
[   78.480037]  [] ? mutex_unlock+0xe/0x10
[   78.480037]  [] lock_release+0xac/0x310
[   78.480037]  [] __mutex_unlock_slowpath+0x83/0x180
[   78.480037]  [] mutex_unlock+0xe/0x10
[   78.480037]  [] p_stop+0x51/0x90
[   78.480037]  [] seq_read+0x288/0x3d0
[   78.480037]  [] vfs_read+0x9e/0x170
[   78.480037]  [] SyS_read+0x4c/0xa0
[   78.480037]  [] system_call_fastpath+0x1a/0x1f

Signed-off-by: John Johansen 
Signed-off-by: James Morris

apparmor: fix memleak of the profile hash

2013-10-16T00:53:59+00:00

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

This fixes the following kmemleak trace:
unreferenced object 0xffff8801e8c35680 (size 32):
  comm "apparmor_parser", pid 691, jiffies 4294895667 (age 13230.876s)
  hex dump (first 32 bytes):
    e0 d3 4e b5 ac 6d f4 ed 3f cb ee 48 1c fd 40 cf  ..N..m..?..H..@.
    5b cc e9 93 00 00 00 00 00 00 00 00 00 00 00 00  [...............
  backtrace:
    [] kmemleak_alloc+0x4e/0xb0
    [] __kmalloc+0x103/0x290
    [] aa_calc_profile_hash+0x6c/0x150
    [] aa_unpack+0x39d/0xd50
    [] aa_replace_profiles+0x3d/0xd80
    [] profile_replace+0x37/0x50
    [] vfs_write+0xbd/0x1e0
    [] SyS_write+0x4c/0xa0
    [] system_call_fastpath+0x1a/0x1f
    [] 0xffffffffffffffff

Signed-off-by: John Johansen 
Signed-off-by: James Morris

selinux: remove 'flags' parameter from avc_audit()

2013-10-04T21:13:25+00:00

Now avc_audit() has no more users with that parameter. Remove it.

Signed-off-by: Linus Torvalds

selinux: avc_has_perm_flags has no more users

2013-10-04T21:13:14+00:00

.. so get rid of it.  The only indirect users were all the
avc_has_perm() callers which just expanded to have a zero flags
argument.

Signed-off-by: Linus Torvalds

selinux: remove 'flags' parameter from inode_has_perm

2013-10-04T19:54:11+00:00

Every single user passes in '0'.  I think we had non-zero users back in
some stone age when selinux_inode_permission() was implemented in terms
of inode_has_perm(), but that complicated case got split up into a
totally separate code-path so that we could optimize the much simpler
special cases.

See commit 2e33405785d3 ("SELinux: delay initialization of audit data in
selinux_inode_permission") for example.

Signed-off-by: Linus Torvalds

apparmor: fix suspicious RCU usage warning in policy.c/policy.h

2013-09-29T23:54:01+00:00

The recent 3.12 pull request for apparmor was missing a couple rcu _protected
access modifiers. Resulting in the follow suspicious RCU usage

 [   29.804534] [ INFO: suspicious RCU usage. ]
 [   29.804539] 3.11.0+ #5 Not tainted
 [   29.804541] -------------------------------
 [   29.804545] security/apparmor/include/policy.h:363 suspicious rcu_dereference_check() usage!
 [   29.804548]
 [   29.804548] other info that might help us debug this:
 [   29.804548]
 [   29.804553]
 [   29.804553] rcu_scheduler_active = 1, debug_locks = 1
 [   29.804558] 2 locks held by apparmor_parser/1268:
 [   29.804560]  #0:  (sb_writers#9){.+.+.+}, at: [] file_start_write+0x27/0x29
 [   29.804576]  #1:  (&ns->lock){+.+.+.}, at: [] aa_replace_profiles+0x166/0x57c
 [   29.804589]
 [   29.804589] stack backtrace:
 [   29.804595] CPU: 0 PID: 1268 Comm: apparmor_parser Not tainted 3.11.0+ #5
 [   29.804599] Hardware name: ASUSTeK Computer Inc.         UL50VT          /UL50VT    , BIOS 217     03/01/2010
 [   29.804602]  0000000000000000 ffff8800b95a1d90 ffffffff8144eb9b ffff8800b94db540
 [   29.804611]  ffff8800b95a1dc0 ffffffff81087439 ffff880138cc3a18 ffff880138cc3a18
 [   29.804619]  ffff8800b9464a90 ffff880138cc3a38 ffff8800b95a1df0 ffffffff811f5084
 [   29.804628] Call Trace:
 [   29.804636]  [] dump_stack+0x4e/0x82
 [   29.804642]  [] lockdep_rcu_suspicious+0xfc/0x105
 [   29.804649]  [] __aa_update_replacedby+0x53/0x7f
 [   29.804655]  [] __replace_profile+0x11f/0x1ed
 [   29.804661]  [] aa_replace_profiles+0x410/0x57c
 [   29.804668]  [] profile_replace+0x35/0x4c
 [   29.804674]  [] vfs_write+0xad/0x113
 [   29.804680]  [] SyS_write+0x44/0x7a
 [   29.804687]  [] system_call_fastpath+0x16/0x1b
 [   29.804691]
 [   29.804694] ===============================
 [   29.804697] [ INFO: suspicious RCU usage. ]
 [   29.804700] 3.11.0+ #5 Not tainted
 [   29.804703] -------------------------------
 [   29.804706] security/apparmor/policy.c:566 suspicious rcu_dereference_check() usage!
 [   29.804709]
 [   29.804709] other info that might help us debug this:
 [   29.804709]
 [   29.804714]
 [   29.804714] rcu_scheduler_active = 1, debug_locks = 1
 [   29.804718] 2 locks held by apparmor_parser/1268:
 [   29.804721]  #0:  (sb_writers#9){.+.+.+}, at: [] file_start_write+0x27/0x29
 [   29.804733]  #1:  (&ns->lock){+.+.+.}, at: [] aa_replace_profiles+0x166/0x57c
 [   29.804744]
 [   29.804744] stack backtrace:
 [   29.804750] CPU: 0 PID: 1268 Comm: apparmor_parser Not tainted 3.11.0+ #5
 [   29.804753] Hardware name: ASUSTeK Computer Inc.         UL50VT          /UL50VT    , BIOS 217     03/01/2010
 [   29.804756]  0000000000000000 ffff8800b95a1d80 ffffffff8144eb9b ffff8800b94db540
 [   29.804764]  ffff8800b95a1db0 ffffffff81087439 ffff8800b95b02b0 0000000000000000
 [   29.804772]  ffff8800b9efba08 ffff880138cc3a38 ffff8800b95a1dd0 ffffffff811f4f94
 [   29.804779] Call Trace:
 [   29.804786]  [] dump_stack+0x4e/0x82
 [   29.804791]  [] lockdep_rcu_suspicious+0xfc/0x105
 [   29.804798]  [] aa_free_replacedby_kref+0x4d/0x62
 [   29.804804]  [] ? aa_put_namespace+0x17/0x17
 [   29.804810]  [] kref_put+0x36/0x40
 [   29.804816]  [] __replace_profile+0x13a/0x1ed
 [   29.804822]  [] aa_replace_profiles+0x410/0x57c
 [   29.804829]  [] profile_replace+0x35/0x4c
 [   29.804835]  [] vfs_write+0xad/0x113
 [   29.804840]  [] SyS_write+0x44/0x7a
 [   29.804847]  [] system_call_fastpath+0x16/0x1b

Reported-by: miles.lane@gmail.com
CC: paulmck@linux.vnet.ibm.com
Signed-off-by: John Johansen 
Signed-off-by: James Morris