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

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

2014-01-08T17:42:12+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-08T17:42:12+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-08T17:42:10+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-08T17:42:10+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:34:20+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:34:20+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-04T18:50:32+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-29T18:50:34+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

key: Fix resource leak

2013-03-28T19:12:27+00:00

commit a84a921978b7d56e0e4b87ffaca6367429b4d8ff upstream.

On an error iov may still have been reallocated and need freeing

Signed-off-by: Alan Cox 
Signed-off-by: David Howells 
Signed-off-by: Greg Kroah-Hartman

selinux: use GFP_ATOMIC under spin_lock

2013-03-20T20:05:00+00:00

commit 4502403dcf8f5c76abd4dbab8726c8e4ecb5cd34 upstream.

The call tree here is:

sk_clone_lock()              <- takes bh_lock_sock(newsk);
xfrm_sk_clone_policy()
__xfrm_sk_clone_policy()
clone_policy()               <- uses GFP_ATOMIC for allocations
security_xfrm_policy_clone()
security_ops->xfrm_policy_clone_security()
selinux_xfrm_policy_clone()

Signed-off-by: Dan Carpenter 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman