linux-toradex.git/security/selinux, branch v3.8.4

selinux: use GFP_ATOMIC under spin_lock

2013-03-20T20:10:56+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

tun: fix LSM/SELinux labeling of tun/tap devices

2013-01-14T23:16:59+00:00

This patch corrects some problems with LSM/SELinux that were introduced
with the multiqueue patchset.  The problem stems from the fact that the
multiqueue work changed the relationship between the tun device and its
associated socket; before the socket persisted for the life of the
device, however after the multiqueue changes the socket only persisted
for the life of the userspace connection (fd open).  For non-persistent
devices this is not an issue, but for persistent devices this can cause
the tun device to lose its SELinux label.

We correct this problem by adding an opaque LSM security blob to the
tun device struct which allows us to have the LSM security state, e.g.
SELinux labeling information, persist for the lifetime of the tun
device.  In the process we tweak the LSM hooks to work with this new
approach to TUN device/socket labeling and introduce a new LSM hook,
security_tun_dev_attach_queue(), to approve requests to attach to a
TUN queue via TUNSETQUEUE.

The SELinux code has been adjusted to match the new LSM hooks, the
other LSMs do not make use of the LSM TUN controls.  This patch makes
use of the recently added "tun_socket:attach_queue" permission to
restrict access to the TUNSETQUEUE operation.  On older SELinux
policies which do not define the "tun_socket:attach_queue" permission
the access control decision for TUNSETQUEUE will be handled according
to the SELinux policy's unknown permission setting.

Signed-off-by: Paul Moore 
Acked-by: Eric Paris 
Tested-by: Jason Wang 
Signed-off-by: David S. Miller

selinux: add the "attach_queue" permission to the "tun_socket" class

2013-01-14T23:16:59+00:00

Add a new permission to align with the new TUN multiqueue support,
"tun_socket:attach_queue".

The corresponding SELinux reference policy patch is show below:

 diff --git a/policy/flask/access_vectors b/policy/flask/access_vectors
 index 28802c5..a0664a1 100644
 --- a/policy/flask/access_vectors
 +++ b/policy/flask/access_vectors
 @@ -827,6 +827,9 @@ class kernel_service

  class tun_socket
  inherits socket
 +{
 +       attach_queue
 +}

  class x_pointer
  inherits x_device

Signed-off-by: Paul Moore 
Acked-by: Eric Paris 
Tested-by: Jason Wang 
Signed-off-by: David S. Miller

bridge: update selinux perm table for RTM_NEWMDB and RTM_DELMDB

2012-12-16T01:14:38+00:00

Cc: Herbert Xu 
Cc: Stephen Hemminger 
Cc: "David S. Miller" 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller

rtnetlink: add missing message types to selinux perm table

2012-12-10T19:09:01+00:00

Rebased on the latest net-next tree.

RTM_NEWNETCONF and RTM_GETNETCONF are missing in this table.

Cc: David S. Miller 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller

bridge: export multicast database via netlink

2012-12-07T19:32:52+00:00

V5: fix two bugs pointed out by Thomas
    remove seq check for now, mark it as TODO

V4: remove some useless #include
    some coding style fix

V3: drop debugging printk's
    update selinux perm table as well

V2: drop patch 1/2, export ifindex directly
    Redesign netlink attributes
    Improve netlink seq check
    Handle IPv6 addr as well

This patch exports bridge multicast database via netlink
message type RTM_GETMDB. Similar to fdb, but currently bridge-specific.
We may need to support modify multicast database too (RTM_{ADD,DEL}MDB).

(Thanks to Thomas for patient reviews)

Cc: Herbert Xu 
Cc: Stephen Hemminger 
Cc: "David S. Miller" 
Cc: Thomas Graf 
Cc: Jesper Dangaard Brouer 
Signed-off-by: Cong Wang 
Acked-by: Thomas Graf 
Signed-off-by: David S. Miller

selinux: fix sel_netnode_insert() suspicious rcu dereference

2012-11-21T10:55:32+00:00

===============================
[ INFO: suspicious RCU usage. ]
3.5.0-rc1+ #63 Not tainted
-------------------------------
security/selinux/netnode.c:178 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
1 lock held by trinity-child1/8750:
 #0:  (sel_netnode_lock){+.....}, at: [] sel_netnode_sid+0x16a/0x3e0

stack backtrace:
Pid: 8750, comm: trinity-child1 Not tainted 3.5.0-rc1+ #63
Call Trace:
 [] lockdep_rcu_suspicious+0xfd/0x130
 [] sel_netnode_sid+0x3b1/0x3e0
 [] ? sel_netnode_find+0x1a0/0x1a0
 [] selinux_socket_bind+0xf6/0x2c0
 [] ? trace_hardirqs_off+0xd/0x10
 [] ? lock_release_holdtime.part.9+0x15/0x1a0
 [] ? lock_hrtimer_base+0x31/0x60
 [] security_socket_bind+0x16/0x20
 [] sys_bind+0x7a/0x100
 [] ? sysret_check+0x22/0x5d
 [] ? trace_hardirqs_on_caller+0x10d/0x1a0
 [] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [] system_call_fastpath+0x16/0x1b

This patch below does what Paul McKenney suggested in the previous thread.

Signed-off-by: Dave Jones 
Reviewed-by: Paul E. McKenney 
Acked-by: Paul Moore 
Cc: Eric Paris 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: James Morris

fix a leak in replace_fd() users

2012-10-16T17:36:50+00:00

replace_fd() began with "eats a reference, tries to insert into
descriptor table" semantics; at some point I'd switched it to
much saner current behaviour ("try to insert into descriptor
table, grabbing a new reference if inserted; caller should do
fput() in any case"), but forgot to update the callers.
Mea culpa...

[Spotted by Pavel Roskin, who has really weird system with pipe-fed
coredumps as part of what he considers a normal boot ;-)]

Signed-off-by: Al Viro

consitify do_mount() arguments

2012-10-12T00:02:04+00:00

Signed-off-by: Al Viro

mm: kill vma flag VM_RESERVED and mm->reserved_vm counter

2012-10-09T07:22:19+00:00

A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA,
currently it lost original meaning but still has some effects:

 | effect                 | alternative flags
-+------------------------+---------------------------------------------
1| account as reserved_vm | VM_IO
2| skip in core dump      | VM_IO, VM_DONTDUMP
3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
4| do not mlock           | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP

This patch removes reserved_vm counter from mm_struct.  Seems like nobody
cares about it, it does not exported into userspace directly, it only
reduces total_vm showed in proc.

Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | VM_DONTDUMP.

remap_pfn_range() and io_remap_pfn_range() set VM_IO|VM_DONTEXPAND|VM_DONTDUMP.
remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP.

[akpm@linux-foundation.org: drivers/vfio/pci/vfio_pci.c fixup]
Signed-off-by: Konstantin Khlebnikov 
Cc: Alexander Viro 
Cc: Carsten Otte 
Cc: Chris Metcalf 
Cc: Cyrill Gorcunov 
Cc: Eric Paris 
Cc: H. Peter Anvin 
Cc: Hugh Dickins 
Cc: Ingo Molnar 
Cc: James Morris 
Cc: Jason Baron 
Cc: Kentaro Takeda 
Cc: Matt Helsley 
Cc: Nick Piggin 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Robert Richter 
Cc: Suresh Siddha 
Cc: Tetsuo Handa 
Cc: Venkatesh Pallipadi 
Acked-by: Linus Torvalds 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds