1. 15 3月, 2014 1 次提交
  2. 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
  3. 25 7月, 2013 1 次提交
  4. 09 6月, 2013 3 次提交
  5. 13 5月, 2013 1 次提交
    • J
      security: cap_inode_getsecctx returning garbage · 0d422afb
      J. Bruce Fields 提交于
      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: NSerge E. Hallyn <serge.hallyn@ubuntu.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      0d422afb
  6. 10 4月, 2013 1 次提交
  7. 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
  8. 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
  9. 14 12月, 2012 1 次提交
  10. 12 10月, 2012 1 次提交
  11. 21 9月, 2012 1 次提交
  12. 01 6月, 2012 1 次提交
  13. 10 4月, 2012 1 次提交
  14. 10 2月, 2012 1 次提交
  15. 07 1月, 2012 1 次提交
  16. 06 1月, 2012 1 次提交
  17. 04 1月, 2012 6 次提交
  18. 20 7月, 2011 1 次提交
  19. 25 4月, 2011 1 次提交
    • A
      SECURITY: Move exec_permission RCU checks into security modules · 1c990429
      Andi Kleen 提交于
      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: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NEric Paris <eparis@redhat.com>
      1c990429
  20. 23 4月, 2011 1 次提交
  21. 04 3月, 2011 1 次提交
    • E
      LSM: Pass -o remount options to the LSM · ff36fe2c
      Eric Paris 提交于
      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: NEric Paris <eparis@redhat.com>
      Reviewed-by: NJames Morris <jmorris@namei.org>
      ff36fe2c
  22. 23 2月, 2011 1 次提交
  23. 02 2月, 2011 2 次提交
    • L
      security: remove unused security_sysctl hook · 4916ca40
      Lucian Adrian Grijincu 提交于
      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: NLucian Adrian Grijincu <lucian.grijincu@gmail.com>
      Signed-off-by: NEric Paris <eparis@redhat.com>
      4916ca40
    • E
      fs/vfs/security: pass last path component to LSM on inode creation · 2a7dba39
      Eric Paris 提交于
      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: NEric Paris <eparis@redhat.com>
      2a7dba39
  24. 06 1月, 2011 1 次提交
  25. 16 11月, 2010 1 次提交
  26. 21 10月, 2010 1 次提交
  27. 02 8月, 2010 2 次提交
  28. 16 7月, 2010 1 次提交
  29. 17 5月, 2010 1 次提交
  30. 12 4月, 2010 2 次提交