1. 11 9月, 2014 1 次提交
    • P
      selinux: make the netif cache namespace aware · cbe0d6e8
      Paul Moore 提交于
      While SELinux largely ignores namespaces, for good reason, there are
      some places where it needs to at least be aware of namespaces in order
      to function correctly.  Network namespaces are one example.  Basic
      awareness of network namespaces are necessary in order to match a
      network interface's index number to an actual network device.
      
      This patch corrects a problem with network interfaces added to a
      non-init namespace, and can be reproduced with the following commands:
      
       [NOTE: the NetLabel configuration is here only to active the dynamic
              networking controls ]
      
       # netlabelctl unlbl add default address:0.0.0.0/0 \
         label:system_u:object_r:unlabeled_t:s0
       # netlabelctl unlbl add default address:::/0 \
         label:system_u:object_r:unlabeled_t:s0
       # netlabelctl cipsov4 add pass doi:100 tags:1
       # netlabelctl map add domain:lspp_test_netlabel_t \
         protocol:cipsov4,100
      
       # ip link add type veth
       # ip netns add myns
       # ip link set veth1 netns myns
       # ip a add dev veth0 10.250.13.100/24
       # ip netns exec myns ip a add dev veth1 10.250.13.101/24
       # ip l set veth0 up
       # ip netns exec myns ip l set veth1 up
      
       # ping -c 1 10.250.13.101
       # ip netns exec myns ping -c 1 10.250.13.100
      Reported-by: NJiri Jaburek <jjaburek@redhat.com>
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      cbe0d6e8
  2. 27 6月, 2014 1 次提交
  3. 19 6月, 2014 1 次提交
  4. 04 6月, 2014 1 次提交
  5. 02 5月, 2014 1 次提交
  6. 23 4月, 2014 1 次提交
  7. 10 3月, 2014 1 次提交
    • N
      selinux: add gfp argument to security_xfrm_policy_alloc and fix callers · 52a4c640
      Nikolay Aleksandrov 提交于
      security_xfrm_policy_alloc can be called in atomic context so the
      allocation should be done with GFP_ATOMIC. Add an argument to let the
      callers choose the appropriate way. In order to do so a gfp argument
      needs to be added to the method xfrm_policy_alloc_security in struct
      security_operations and to the internal function
      selinux_xfrm_alloc_user. After that switch to GFP_ATOMIC in the atomic
      callers and leave GFP_KERNEL as before for the rest.
      The path that needed the gfp argument addition is:
      security_xfrm_policy_alloc -> security_ops.xfrm_policy_alloc_security ->
      all users of xfrm_policy_alloc_security (e.g. selinux_xfrm_policy_alloc) ->
      selinux_xfrm_alloc_user (here the allocation used to be GFP_KERNEL only)
      
      Now adding a gfp argument to selinux_xfrm_alloc_user requires us to also
      add it to security_context_to_sid which is used inside and prior to this
      patch did only GFP_KERNEL allocation. So add gfp argument to
      security_context_to_sid and adjust all of its callers as well.
      
      CC: Paul Moore <paul@paul-moore.com>
      CC: Dave Jones <davej@redhat.com>
      CC: Steffen Klassert <steffen.klassert@secunet.com>
      CC: Fan Du <fan.du@windriver.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: LSM list <linux-security-module@vger.kernel.org>
      CC: SELinux list <selinux@tycho.nsa.gov>
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Acked-by: NPaul Moore <paul@paul-moore.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      52a4c640
  8. 12 2月, 2014 1 次提交
    • F
      flowcache: Make flow cache name space aware · ca925cf1
      Fan Du 提交于
      Inserting a entry into flowcache, or flushing flowcache should be based
      on per net scope. The reason to do so is flushing operation from fat
      netns crammed with flow entries will also making the slim netns with only
      a few flow cache entries go away in original implementation.
      
      Since flowcache is tightly coupled with IPsec, so it would be easier to
      put flow cache global parameters into xfrm namespace part. And one last
      thing needs to do is bumping flow cache genid, and flush flow cache should
      also be made in per net style.
      Signed-off-by: NFan Du <fan.du@windriver.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      ca925cf1
  9. 12 1月, 2014 1 次提交
    • S
      SELinux: Fix possible NULL pointer dereference in selinux_inode_permission() · 3dc91d43
      Steven Rostedt 提交于
      While running stress tests on adding and deleting ftrace instances I hit
      this bug:
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
        IP: selinux_inode_permission+0x85/0x160
        PGD 63681067 PUD 7ddbe067 PMD 0
        Oops: 0000 [#1] PREEMPT
        CPU: 0 PID: 5634 Comm: ftrace-test-mki Not tainted 3.13.0-rc4-test-00033-gd2a6dde-dirty #20
        Hardware name:                  /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006
        task: ffff880078375800 ti: ffff88007ddb0000 task.ti: ffff88007ddb0000
        RIP: 0010:[<ffffffff812d8bc5>]  [<ffffffff812d8bc5>] selinux_inode_permission+0x85/0x160
        RSP: 0018:ffff88007ddb1c48  EFLAGS: 00010246
        RAX: 0000000000000000 RBX: 0000000000800000 RCX: ffff88006dd43840
        RDX: 0000000000000001 RSI: 0000000000000081 RDI: ffff88006ee46000
        RBP: ffff88007ddb1c88 R08: 0000000000000000 R09: ffff88007ddb1c54
        R10: 6e6576652f6f6f66 R11: 0000000000000003 R12: 0000000000000000
        R13: 0000000000000081 R14: ffff88006ee46000 R15: 0000000000000000
        FS:  00007f217b5b6700(0000) GS:ffffffff81e21000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033^M
        CR2: 0000000000000020 CR3: 000000006a0fe000 CR4: 00000000000007f0
        Call Trace:
          security_inode_permission+0x1c/0x30
          __inode_permission+0x41/0xa0
          inode_permission+0x18/0x50
          link_path_walk+0x66/0x920
          path_openat+0xa6/0x6c0
          do_filp_open+0x43/0xa0
          do_sys_open+0x146/0x240
          SyS_open+0x1e/0x20
          system_call_fastpath+0x16/0x1b
        Code: 84 a1 00 00 00 81 e3 00 20 00 00 89 d8 83 c8 02 40 f6 c6 04 0f 45 d8 40 f6 c6 08 74 71 80 cf 02 49 8b 46 38 4c 8d 4d cc 45 31 c0 <0f> b7 50 20 8b 70 1c 48 8b 41 70 89 d9 8b 78 04 e8 36 cf ff ff
        RIP  selinux_inode_permission+0x85/0x160
        CR2: 0000000000000020
      
      Investigating, I found that the inode->i_security was NULL, and the
      dereference of it caused the oops.
      
      in selinux_inode_permission():
      
      	isec = inode->i_security;
      
      	rc = avc_has_perm_noaudit(sid, isec->sid, isec->sclass, perms, 0, &avd);
      
      Note, the crash came from stressing the deletion and reading of debugfs
      files.  I was not able to recreate this via normal files.  But I'm not
      sure they are safe.  It may just be that the race window is much harder
      to hit.
      
      What seems to have happened (and what I have traced), is the file is
      being opened at the same time the file or directory is being deleted.
      As the dentry and inode locks are not held during the path walk, nor is
      the inodes ref counts being incremented, there is nothing saving these
      structures from being discarded except for an rcu_read_lock().
      
      The rcu_read_lock() protects against freeing of the inode, but it does
      not protect freeing of the inode_security_struct.  Now if the freeing of
      the i_security happens with a call_rcu(), and the i_security field of
      the inode is not changed (it gets freed as the inode gets freed) then
      there will be no issue here.  (Linus Torvalds suggested not setting the
      field to NULL such that we do not need to check if it is NULL in the
      permission check).
      
      Note, this is a hack, but it fixes the problem at hand.  A real fix is
      to restructure the destroy_inode() to call all the destructor handlers
      from the RCU callback.  But that is a major job to do, and requires a
      lot of work.  For now, we just band-aid this bug with this fix (it
      works), and work on a more maintainable solution in the future.
      
      Link: http://lkml.kernel.org/r/20140109101932.0508dec7@gandalf.local.home
      Link: http://lkml.kernel.org/r/20140109182756.17abaaa8@gandalf.local.home
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3dc91d43
  10. 13 12月, 2013 1 次提交
  11. 10 12月, 2013 1 次提交
  12. 20 11月, 2013 1 次提交
  13. 05 10月, 2013 2 次提交
  14. 29 8月, 2013 1 次提交
  15. 01 8月, 2013 1 次提交
  16. 26 7月, 2013 10 次提交
  17. 09 6月, 2013 1 次提交
  18. 15 1月, 2013 2 次提交
    • P
      tun: fix LSM/SELinux labeling of tun/tap devices · 5dbbaf2d
      Paul Moore 提交于
      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: NPaul Moore <pmoore@redhat.com>
      Acked-by: NEric Paris <eparis@parisplace.org>
      Tested-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5dbbaf2d
    • P
      selinux: add the "attach_queue" permission to the "tun_socket" class · 6f96c142
      Paul Moore 提交于
      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: NPaul Moore <pmoore@redhat.com>
      Acked-by: NEric Paris <eparis@parisplace.org>
      Tested-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6f96c142
  19. 19 9月, 2012 1 次提交
  20. 23 7月, 2012 1 次提交
  21. 16 7月, 2012 1 次提交
  22. 10 4月, 2012 6 次提交
    • W
      SELinux: avc: remove the useless fields in avc_add_callback · 562c99f2
      Wanlong Gao 提交于
      avc_add_callback now just used for registering reset functions
      in initcalls, and the callback functions just did reset operations.
      So, reducing the arguments to only one event is enough now.
      Signed-off-by: NWanlong Gao <gaowanlong@cn.fujitsu.com>
      Signed-off-by: NEric Paris <eparis@redhat.com>
      562c99f2
    • E
      SELinux: unify the selinux_audit_data and selinux_late_audit_data · 899838b2
      Eric Paris 提交于
      We no longer need the distinction.  We only need data after we decide to do an
      audit.  So turn the "late" audit data into just "data" and remove what we
      currently have as "data".
      Signed-off-by: NEric Paris <eparis@redhat.com>
      899838b2
    • E
      SELinux: remove auditdeny from selinux_audit_data · 1d349292
      Eric Paris 提交于
      It's just takin' up space.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      1d349292
    • E
      SELinux: delay initialization of audit data in selinux_inode_permission · 2e334057
      Eric Paris 提交于
      We pay a rather large overhead initializing the common_audit_data.
      Since we only need this information if we actually emit an audit
      message there is little need to set it up in the hot path.  This patch
      splits the functionality of avc_has_perm() into avc_has_perm_noaudit(),
      avc_audit_required() and slow_avc_audit().  But we take care of setting
      up to audit between required() and the actual audit call.  Thus saving
      measurable time in a hot path.
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NEric Paris <eparis@redhat.com>
      2e334057
    • E
      SELinux: add default_type statements · eed7795d
      Eric Paris 提交于
      Because Fedora shipped userspace based on my development tree we now
      have policy version 27 in the wild defining only default user, role, and
      range.  Thus to add default_type we need a policy.28.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      eed7795d
    • E
      SELinux: allow default source/target selectors for user/role/range · aa893269
      Eric Paris 提交于
      When new objects are created we have great and flexible rules to
      determine the type of the new object.  We aren't quite as flexible or
      mature when it comes to determining the user, role, and range.  This
      patch adds a new ability to specify the place a new objects user, role,
      and range should come from.  For users and roles it can come from either
      the source or the target of the operation.  aka for files the user can
      either come from the source (the running process and todays default) or
      it can come from the target (aka the parent directory of the new file)
      
      examples always are done with
      directory context: system_u:object_r:mnt_t:s0-s0:c0.c512
      process context: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
      
      [no rule]
      	unconfined_u:object_r:mnt_t:s0   test_none
      [default user source]
      	unconfined_u:object_r:mnt_t:s0   test_user_source
      [default user target]
      	system_u:object_r:mnt_t:s0       test_user_target
      [default role source]
      	unconfined_u:unconfined_r:mnt_t:s0 test_role_source
      [default role target]
      	unconfined_u:object_r:mnt_t:s0   test_role_target
      [default range source low]
      	unconfined_u:object_r:mnt_t:s0 test_range_source_low
      [default range source high]
      	unconfined_u:object_r:mnt_t:s0:c0.c1023 test_range_source_high
      [default range source low-high]
      	unconfined_u:object_r:mnt_t:s0-s0:c0.c1023 test_range_source_low-high
      [default range target low]
      	unconfined_u:object_r:mnt_t:s0 test_range_target_low
      [default range target high]
      	unconfined_u:object_r:mnt_t:s0:c0.c512 test_range_target_high
      [default range target low-high]
      	unconfined_u:object_r:mnt_t:s0-s0:c0.c512 test_range_target_low-high
      Signed-off-by: NEric Paris <eparis@redhat.com>
      aa893269
  23. 04 4月, 2012 2 次提交