1. 14 12月, 2013 1 次提交
    • P
      selinux: revert 102aefdd · 4d546f81
      Paul Moore 提交于
      Revert "selinux: consider filesystem subtype in policies"
      
      This reverts commit 102aefdd.
      
      Explanation from Eric Paris:
      
      	SELinux policy can specify if it should use a filesystem's
      	xattrs or not.  In current policy we have a specification that
      	fuse should not use xattrs but fuse.glusterfs should use
      	xattrs.  This patch has a bug in which non-glusterfs
      	filesystems would match the rule saying fuse.glusterfs should
      	use xattrs.  If both fuse and the particular filesystem in
      	question are not written to handle xattr calls during the mount
      	command, they will deadlock.
      
      	I have fixed the bug to do proper matching, however I believe a
      	revert is still the correct solution.  The reason I believe
      	that is because the code still does not work.  The s_subtype is
      	not set until after the SELinux hook which attempts to match on
      	the ".gluster" portion of the rule.  So we cannot match on the
      	rule in question.  The code is useless.
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      4d546f81
  2. 12 12月, 2013 1 次提交
  3. 11 12月, 2013 1 次提交
  4. 10 12月, 2013 1 次提交
  5. 05 12月, 2013 4 次提交
    • P
      selinux: pull address family directly from the request_sock struct · 0b1f24e6
      Paul Moore 提交于
      We don't need to inspect the packet to determine if the packet is an
      IPv4 packet arriving on an IPv6 socket when we can query the
      request_sock directly.
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      0b1f24e6
    • P
      selinux: ensure that the cached NetLabel secattr matches the desired SID · 050d032b
      Paul Moore 提交于
      In selinux_netlbl_skbuff_setsid() we leverage a cached NetLabel
      secattr whenever possible.  However, we never check to ensure that
      the desired SID matches the cached NetLabel secattr.  This patch
      checks the SID against the secattr before use and only uses the
      cached secattr when the SID values match.
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      050d032b
    • P
      selinux: handle TCP SYN-ACK packets correctly in selinux_ip_postroute() · 7f721643
      Paul Moore 提交于
      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: NJanak Desai <Janak.Desai@gtri.gatech.edu>
      Tested-by: NJanak Desai <Janak.Desai@gtri.gatech.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      7f721643
    • P
      selinux: handle TCP SYN-ACK packets correctly in selinux_ip_output() · da2ea0d0
      Paul Moore 提交于
      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: NJanak Desai <Janak.Desai@gtri.gatech.edu>
      Tested-by: NJanak Desai <Janak.Desai@gtri.gatech.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      da2ea0d0
  6. 26 11月, 2013 1 次提交
  7. 20 11月, 2013 2 次提交
  8. 09 11月, 2013 1 次提交
  9. 04 11月, 2013 3 次提交
  10. 03 11月, 2013 2 次提交
  11. 02 11月, 2013 20 次提交
  12. 01 11月, 2013 3 次提交
    • L
      Merge branch 'akpm' (fixes from Andrew Morton) · 4f794ee8
      Linus Torvalds 提交于
      Merge four more fixes from Andrew Morton.
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        lib/scatterlist.c: don't flush_kernel_dcache_page on slab page
        mm: memcg: fix test for child groups
        mm: memcg: lockdep annotation for memcg OOM lock
        mm: memcg: use proper memcg in limit bypass
      4f794ee8
    • M
      lib/scatterlist.c: don't flush_kernel_dcache_page on slab page · 3d77b50c
      Ming Lei 提交于
      Commit b1adaf65 ("[SCSI] block: add sg buffer copy helper
      functions") introduces two sg buffer copy helpers, and calls
      flush_kernel_dcache_page() on pages in SG list after these pages are
      written to.
      
      Unfortunately, the commit may introduce a potential bug:
      
       - Before sending some SCSI commands, kmalloc() buffer may be passed to
         block layper, so flush_kernel_dcache_page() can see a slab page
         finally
      
       - According to cachetlb.txt, flush_kernel_dcache_page() is only called
         on "a user page", which surely can't be a slab page.
      
       - ARCH's implementation of flush_kernel_dcache_page() may use page
         mapping information to do optimization so page_mapping() will see the
         slab page, then VM_BUG_ON() is triggered.
      
      Aaro Koskinen reported the bug on ARM/kirkwood when DEBUG_VM is enabled,
      and this patch fixes the bug by adding test of '!PageSlab(miter->page)'
      before calling flush_kernel_dcache_page().
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Reported-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Tested-by: NSimon Baatz <gmbnomis@gmail.com>
      Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: <stable@vger.kernel.org>	[3.2+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3d77b50c
    • J
      mm: memcg: fix test for child groups · 696ac172
      Johannes Weiner 提交于
      When memcg code needs to know whether any given memcg has children, it
      uses the cgroup child iteration primitives and returns true/false
      depending on whether the iteration loop is executed at least once or
      not.
      
      Because a cgroup's list of children is RCU protected, these primitives
      require the RCU read-lock to be held, which is not the case for all
      memcg callers.  This results in the following splat when e.g.  enabling
      hierarchy mode:
      
        WARNING: CPU: 3 PID: 1 at kernel/cgroup.c:3043 css_next_child+0xa3/0x160()
        CPU: 3 PID: 1 Comm: systemd Not tainted 3.12.0-rc5-00117-g83f11a9c-dirty #18
        Hardware name: LENOVO 3680B56/3680B56, BIOS 6QET69WW (1.39 ) 04/26/2012
        Call Trace:
          dump_stack+0x54/0x74
          warn_slowpath_common+0x78/0xa0
          warn_slowpath_null+0x1a/0x20
          css_next_child+0xa3/0x160
          mem_cgroup_hierarchy_write+0x5b/0xa0
          cgroup_file_write+0x108/0x2a0
          vfs_write+0xbd/0x1e0
          SyS_write+0x4c/0xa0
          system_call_fastpath+0x16/0x1b
      
      In the memcg case, we only care about children when we are attempting to
      modify inheritable attributes interactively.  Racing with deletion could
      mean a spurious -EBUSY, no problem.  Racing with addition is handled
      just fine as well through the memcg_create_mutex: if the child group is
      not on the list after the mutex is acquired, it won't be initialized
      from the parent's attributes until after the unlock.
      Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: NMichal Hocko <mhocko@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      696ac172