1. 09 Sep, 2014 1 commit
  2. 25 Jul, 2014 1 commit
  3. 14 Mar, 2014 1 commit
  4. 10 Mar, 2014 1 commit
    • Nikolay Aleksandrov's avatar
      selinux: add gfp argument to security_xfrm_policy_alloc and fix callers · 52a4c640
      Nikolay Aleksandrov authored
      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: default avatarNikolay Aleksandrov <nikolay@redhat.com>
      Acked-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      52a4c640
  5. 07 Mar, 2014 1 commit
  6. 25 Jul, 2013 2 commits
  7. 08 Jun, 2013 3 commits
  8. 13 May, 2013 1 commit
    • J. Bruce Fields's avatar
      security: cap_inode_getsecctx returning garbage · 0d422afb
      J. Bruce Fields authored
      We shouldn't be returning success from this function without also
      filling in the return values ctx and ctxlen.
      
      Note currently this doesn't appear to cause bugs since the only
      inode_getsecctx caller I can find is fs/sysfs/inode.c, which only calls
      this if security_inode_setsecurity succeeds.  Assuming
      security_inode_setsecurity is set to cap_inode_setsecurity whenever
      inode_getsecctx is set to cap_inode_getsecctx, this function can never
      actually called.
      
      So I noticed this only because the server labeled NFS patches add a real
      caller.
      Acked-by: default avatarSerge E. Hallyn <serge.hallyn@ubuntu.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      0d422afb
  9. 09 Apr, 2013 1 commit
  10. 02 Apr, 2013 1 commit
    • Jeff Layton's avatar
      selinux: make security_sb_clone_mnt_opts return an error on context mismatch · 094f7b69
      Jeff Layton authored
      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: default avatarJeff Layton <jlayton@redhat.com>
      Acked-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      094f7b69
  11. 14 Jan, 2013 1 commit
    • Paul Moore's avatar
      tun: fix LSM/SELinux labeling of tun/tap devices · 5dbbaf2d
      Paul Moore authored
      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: default avatarPaul Moore <pmoore@redhat.com>
      Acked-by: default avatarEric Paris <eparis@parisplace.org>
      Tested-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5dbbaf2d
  12. 14 Dec, 2012 1 commit
  13. 12 Oct, 2012 1 commit
  14. 21 Sep, 2012 1 commit
  15. 31 May, 2012 1 commit
  16. 09 Apr, 2012 1 commit
  17. 09 Feb, 2012 1 commit
  18. 07 Jan, 2012 1 commit
  19. 05 Jan, 2012 1 commit
  20. 04 Jan, 2012 6 commits
  21. 20 Jul, 2011 1 commit
  22. 25 Apr, 2011 1 commit
    • Andi Kleen's avatar
      SECURITY: Move exec_permission RCU checks into security modules · 1c990429
      Andi Kleen authored
      Right now all RCU walks fall back to reference walk when CONFIG_SECURITY
      is enabled, even though just the standard capability module is active.
      This is because security_inode_exec_permission unconditionally fails
      RCU walks.
      
      Move this decision to the low level security module. This requires
      passing the RCU flags down the security hook. This way at least
      the capability module and a few easy cases in selinux/smack work
      with RCU walks with CONFIG_SECURITY=y
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      1c990429
  23. 22 Apr, 2011 1 commit
  24. 03 Mar, 2011 1 commit
    • Eric Paris's avatar
      LSM: Pass -o remount options to the LSM · ff36fe2c
      Eric Paris authored
      The VFS mount code passes the mount options to the LSM.  The LSM will remove
      options it understands from the data and the VFS will then pass the remaining
      options onto the underlying filesystem.  This is how options like the
      SELinux context= work.  The problem comes in that -o remount never calls
      into LSM code.  So if you include an LSM specific option it will get passed
      to the filesystem and will cause the remount to fail.  An example of where
      this is a problem is the 'seclabel' option.  The SELinux LSM hook will
      print this word in /proc/mounts if the filesystem is being labeled using
      xattrs.  If you pass this word on mount it will be silently stripped and
      ignored.  But if you pass this word on remount the LSM never gets called
      and it will be passed to the FS.  The FS doesn't know what seclabel means
      and thus should fail the mount.  For example an ext3 fs mounted over loop
      
      # mount -o loop /tmp/fs /mnt/tmp
      # cat /proc/mounts | grep /mnt/tmp
      /dev/loop0 /mnt/tmp ext3 rw,seclabel,relatime,errors=continue,barrier=0,data=ordered 0 0
      # mount -o remount /mnt/tmp
      mount: /mnt/tmp not mounted already, or bad option
      # dmesg
      EXT3-fs (loop0): error: unrecognized mount option "seclabel" or missing value
      
      This patch passes the remount mount options to an new LSM hook.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Reviewed-by: default avatarJames Morris <jmorris@namei.org>
      ff36fe2c
  25. 23 Feb, 2011 1 commit
  26. 01 Feb, 2011 2 commits
    • Lucian Adrian Grijincu's avatar
      security: remove unused security_sysctl hook · 4916ca40
      Lucian Adrian Grijincu authored
      The only user for this hook was selinux. sysctl routes every call
      through /proc/sys/. Selinux and other security modules use the file
      system checks for sysctl too, so no need for this hook any more.
      Signed-off-by: default avatarLucian Adrian Grijincu <lucian.grijincu@gmail.com>
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      4916ca40
    • Eric Paris's avatar
      fs/vfs/security: pass last path component to LSM on inode creation · 2a7dba39
      Eric Paris authored
      SELinux would like to implement a new labeling behavior of newly created
      inodes.  We currently label new inodes based on the parent and the creating
      process.  This new behavior would also take into account the name of the
      new object when deciding the new label.  This is not the (supposed) full path,
      just the last component of the path.
      
      This is very useful because creating /etc/shadow is different than creating
      /etc/passwd but the kernel hooks are unable to differentiate these
      operations.  We currently require that userspace realize it is doing some
      difficult operation like that and than userspace jumps through SELinux hoops
      to get things set up correctly.  This patch does not implement new
      behavior, that is obviously contained in a seperate SELinux patch, but it
      does pass the needed name down to the correct LSM hook.  If no such name
      exists it is fine to pass NULL.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      2a7dba39
  27. 05 Jan, 2011 1 commit
  28. 15 Nov, 2010 1 commit
  29. 20 Oct, 2010 1 commit
  30. 02 Aug, 2010 2 commits