1. 23 4月, 2016 1 次提交
    • B
      security: Introduce security_settime64() · 457db29b
      Baolin Wang 提交于
      security_settime() uses a timespec, which is not year 2038 safe
      on 32bit systems. Thus this patch introduces the security_settime64()
      function with timespec64 type. We also convert the cap_settime() helper
      function to use the 64bit types.
      
      This patch then moves security_settime() to the header file as an
      inline helper function so that existing users can be iteratively
      converted.
      
      None of the existing hooks is using the timespec argument and therefor
      the patch is not making any functional changes.
      
      Cc: Serge Hallyn <serge.hallyn@canonical.com>,
      Cc: James Morris <james.l.morris@oracle.com>,
      Cc: "Serge E. Hallyn" <serge@hallyn.com>,
      Cc: Paul Moore <pmoore@redhat.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Reviewed-by: NJames Morris <james.l.morris@oracle.com>
      Signed-off-by: NBaolin Wang <baolin.wang@linaro.org>
      [jstultz: Reworded commit message]
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      457db29b
  2. 21 2月, 2016 4 次提交
  3. 19 2月, 2016 2 次提交
  4. 25 12月, 2015 3 次提交
  5. 26 8月, 2015 1 次提交
  6. 28 7月, 2015 1 次提交
  7. 10 7月, 2015 1 次提交
    • E
      vfs: Commit to never having exectuables on proc and sysfs. · 90f8572b
      Eric W. Biederman 提交于
      Today proc and sysfs do not contain any executable files.  Several
      applications today mount proc or sysfs without noexec and nosuid and
      then depend on there being no exectuables files on proc or sysfs.
      Having any executable files show on proc or sysfs would cause
      a user space visible regression, and most likely security problems.
      
      Therefore commit to never allowing executables on proc and sysfs by
      adding a new flag to mark them as filesystems without executables and
      enforce that flag.
      
      Test the flag where MNT_NOEXEC is tested today, so that the only user
      visible effect will be that exectuables will be treated as if the
      execute bit is cleared.
      
      The filesystems proc and sysfs do not currently incoporate any
      executable files so this does not result in any user visible effects.
      
      This makes it unnecessary to vet changes to proc and sysfs tightly for
      adding exectuable files or changes to chattr that would modify
      existing files, as no matter what the individual file say they will
      not be treated as exectuable files by the vfs.
      
      Not having to vet changes to closely is important as without this we
      are only one proc_create call (or another goof up in the
      implementation of notify_change) from having problematic executables
      on proc.  Those mistakes are all too easy to make and would create
      a situation where there are security issues or the assumptions of
      some program having to be broken (and cause userspace regressions).
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      90f8572b
  8. 12 5月, 2015 3 次提交
  9. 11 5月, 2015 2 次提交
    • N
      security: make inode_follow_link RCU-walk aware · bda0be7a
      NeilBrown 提交于
      inode_follow_link now takes an inode and rcu flag as well as the
      dentry.
      
      inode is used in preference to d_backing_inode(dentry), particularly
      in RCU-walk mode.
      
      selinux_inode_follow_link() gets dentry_has_perm() and
      inode_has_perm() open-coded into it so that it can call
      avc_has_perm_flags() in way that is safe if LOOKUP_RCU is set.
      
      Calling avc_has_perm_flags() with rcu_read_lock() held means
      that when avc_has_perm_noaudit calls avc_compute_av(), the attempt
      to rcu_read_unlock() before calling security_compute_av() will not
      actually drop the RCU read-lock.
      
      However as security_compute_av() is completely in a read_lock()ed
      region, it should be safe with the RCU read-lock held.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      bda0be7a
    • N
      SECURITY: remove nameidata arg from inode_follow_link. · 37882db0
      NeilBrown 提交于
      No ->inode_follow_link() methods use the nameidata arg, and
      it is about to become private to namei.c.
      So remove from all inode_follow_link() functions.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      37882db0
  10. 16 4月, 2015 1 次提交
  11. 12 4月, 2015 1 次提交
  12. 21 3月, 2015 1 次提交
  13. 26 1月, 2015 1 次提交
    • S
      Add security hooks to binder and implement the hooks for SELinux. · 79af7307
      Stephen Smalley 提交于
      Add security hooks to the binder and implement the hooks for SELinux.
      The security hooks enable security modules such as SELinux to implement
      controls over binder IPC.  The security hooks include support for
      controlling what process can become the binder context manager
      (binder_set_context_mgr), controlling the ability of a process
      to invoke a binder transaction/IPC to another process (binder_transaction),
      controlling the ability of a process to transfer a binder reference to
      another process (binder_transfer_binder), and controlling the ability
      of a process to transfer an open file to another process (binder_transfer_file).
      
      These hooks have been included in the Android kernel trees since Android 4.3.
      
      (Updated to reflect upstream relocation and changes to the binder driver,
      changes to the LSM audit data structures, coding style cleanups, and
      to add inline documentation for the hooks).
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Acked-by: NNick Kralevich <nnk@google.com>
      Acked-by: NJeffrey Vander Stoep <jeffv@google.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      79af7307
  14. 21 1月, 2015 1 次提交
  15. 10 9月, 2014 1 次提交
  16. 26 7月, 2014 2 次提交
  17. 01 4月, 2014 2 次提交
  18. 15 3月, 2014 1 次提交
  19. 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
  20. 26 7月, 2013 1 次提交
    • P
      lsm: split the xfrm_state_alloc_security() hook implementation · 2e5aa866
      Paul Moore 提交于
      The xfrm_state_alloc_security() LSM hook implementation is really a
      multiplexed hook with two different behaviors depending on the
      arguments passed to it by the caller.  This patch splits the LSM hook
      implementation into two new hook implementations, which match the
      LSM hooks in the rest of the kernel:
      
       * xfrm_state_alloc
       * xfrm_state_alloc_acquire
      
      Also included in this patch are the necessary changes to the SELinux
      code; no other LSMs are affected.
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      Signed-off-by: NEric Paris <eparis@redhat.com>
      2e5aa866
  21. 25 7月, 2013 1 次提交
  22. 09 6月, 2013 4 次提交
  23. 10 4月, 2013 1 次提交
  24. 02 4月, 2013 1 次提交
    • J
      selinux: make security_sb_clone_mnt_opts return an error on context mismatch · 094f7b69
      Jeff Layton 提交于
      I had the following problem reported a while back. If you mount the
      same filesystem twice using NFSv4 with different contexts, then the
      second context= option is ignored. For instance:
      
          # mount server:/export /mnt/test1
          # mount server:/export /mnt/test2 -o context=system_u:object_r:tmp_t:s0
          # ls -dZ /mnt/test1
          drwxrwxrwt. root root system_u:object_r:nfs_t:s0       /mnt/test1
          # ls -dZ /mnt/test2
          drwxrwxrwt. root root system_u:object_r:nfs_t:s0       /mnt/test2
      
      When we call into SELinux to set the context of a "cloned" superblock,
      it will currently just bail out when it notices that we're reusing an
      existing superblock. Since the existing superblock is already set up and
      presumably in use, we can't go overwriting its context with the one from
      the "original" sb. Because of this, the second context= option in this
      case cannot take effect.
      
      This patch fixes this by turning security_sb_clone_mnt_opts into an int
      return operation. When it finds that the "new" superblock that it has
      been handed is already set up, it checks to see whether the contexts on
      the old superblock match it. If it does, then it will just return
      success, otherwise it'll return -EBUSY and emit a printk to tell the
      admin why the second mount failed.
      
      Note that this patch may cause casualties. The NFSv4 code relies on
      being able to walk down to an export from the pseudoroot. If you mount
      filesystems that are nested within one another with different contexts,
      then this patch will make those mounts fail in new and "exciting" ways.
      
      For instance, suppose that /export is a separate filesystem on the
      server:
      
          # mount server:/ /mnt/test1
          # mount salusa:/export /mnt/test2 -o context=system_u:object_r:tmp_t:s0
          mount.nfs: an incorrect mount option was specified
      
      ...with the printk in the ring buffer. Because we *might* eventually
      walk down to /mnt/test1/export, the mount is denied due to this patch.
      The second mount needs the pseudoroot superblock, but that's already
      present with the wrong context.
      
      OTOH, if we mount these in the reverse order, then both mounts work,
      because the pseudoroot superblock created when mounting /export is
      discarded once that mount is done. If we then however try to walk into
      that directory, the automount fails for the similar reasons:
      
          # cd /mnt/test1/scratch/
          -bash: cd: /mnt/test1/scratch: Device or resource busy
      
      The story I've gotten from the SELinux folks that I've talked to is that
      this is desirable behavior. In SELinux-land, mounting the same data
      under different contexts is wrong -- there can be only one.
      
      Cc: Steve Dickson <steved@redhat.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Acked-by: NEric Paris <eparis@redhat.com>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      094f7b69
  25. 15 1月, 2013 1 次提交
    • 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
  26. 14 12月, 2012 1 次提交
    • M
      ima: support new kernel module syscall · fdf90729
      Mimi Zohar 提交于
      With the addition of the new kernel module syscall, which defines two
      arguments - a file descriptor to the kernel module and a pointer to a NULL
      terminated string of module arguments - it is now possible to measure and
      appraise kernel modules like any other file on the file system.
      
      This patch adds support to measure and appraise kernel modules in an
      extensible and consistent manner.
      
      To support filesystems without extended attribute support, additional
      patches could pass the signature as the first parameter.
      Signed-off-by: NMimi Zohar <zohar@us.ibm.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      fdf90729