linux-toradex.git/security, branch v3.12.8

selinux: process labeled IPsec TCP SYN-ACK packets properly in selinux_ip_postroute()

2014-01-09T20:25:15+00:00

commit c0828e50485932b7e019df377a6b0a8d1ebd3080 upstream.

Due to difficulty in arriving at the proper security label for
TCP SYN-ACK packets in selinux_ip_postroute(), we need to check packets
while/before they are undergoing XFRM transforms instead of waiting
until afterwards so that we can determine the correct security label.

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

selinux: look for IPsec labels on both inbound and outbound packets

2014-01-09T20:25:15+00:00

commit 817eff718dca4e54d5721211ddde0914428fbb7c upstream.

Previously selinux_skb_peerlbl_sid() would only check for labeled
IPsec security labels on inbound packets, this patch enables it to
check both inbound and outbound traffic for labeled IPsec security
labels.

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

selinux: selinux_setprocattr()->ptrace_parent() needs rcu_read_lock()

2014-01-09T20:25:08+00:00

commit c0c1439541f5305b57a83d599af32b74182933fe upstream.

selinux_setprocattr() does ptrace_parent(p) under task_lock(p),
but task_struct->alloc_lock doesn't pin ->parent or ->ptrace,
this looks confusing and triggers the "suspicious RCU usage"
warning because ptrace_parent() does rcu_dereference_check().

And in theory this is wrong, spin_lock()->preempt_disable()
doesn't necessarily imply rcu_read_lock() we need to access
the ->parent.

Reported-by: Evan McNabb 
Signed-off-by: Oleg Nesterov 
Signed-off-by: Paul Moore 
Signed-off-by: Greg Kroah-Hartman

selinux: fix broken peer recv check

2014-01-09T20:25:08+00:00

commit 46d01d63221c3508421dd72ff9c879f61053cffc upstream.

Fix a broken networking check. Return an error if peer recv fails.  If
secmark is active and the packet recv succeeds the peer recv error is
ignored.

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

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