1. 09 Sep, 2014 1 commit
  2. 28 Jul, 2014 1 commit
  3. 25 Jul, 2014 1 commit
  4. 10 Jul, 2014 1 commit
    • Paul Moore's avatar
      selinux: fix the default socket labeling in sock_graft() · 4da6daf4
      Paul Moore authored
      The sock_graft() hook has special handling for AF_INET, AF_INET, and
      AF_UNIX sockets as those address families have special hooks which
      label the sock before it is attached its associated socket.
      Unfortunately, the sock_graft() hook was missing a default approach
      to labeling sockets which meant that any other address family which
      made use of connections or the accept() syscall would find the
      returned socket to be in an "unlabeled" state.  This was recently
      demonstrated by the kcrypto/AF_ALG subsystem and the newly released
      cryptsetup package (cryptsetup v1.6.5 and later).
      This patch preserves the special handling in selinux_sock_graft(),
      but adds a default behavior - setting the sock's label equal to the
      associated socket - which resolves the problem with AF_ALG and
      presumably any other address family which makes use of accept().
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Tested-by: default avatarMilan Broz <gmazyland@gmail.com>
  5. 01 Apr, 2014 1 commit
  6. 14 Mar, 2014 1 commit
  7. 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>
  8. 25 Jul, 2013 2 commits
  9. 08 Jun, 2013 4 commits
  10. 12 May, 2013 1 commit
  11. 10 Apr, 2013 1 commit
  12. 09 Apr, 2013 1 commit
  13. 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
          # 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>
  14. 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>
  15. 14 Dec, 2012 1 commit
  16. 12 Oct, 2012 1 commit
  17. 25 Sep, 2012 1 commit
  18. 21 Sep, 2012 1 commit
  19. 05 Sep, 2012 1 commit
  20. 10 Aug, 2012 1 commit
  21. 01 Jun, 2012 1 commit
  22. 31 May, 2012 2 commits
  23. 14 Apr, 2012 1 commit
    • Andy Lutomirski's avatar
      Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs · 259e5e6c
      Andy Lutomirski authored
      With this change, calling
        prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)
      disables privilege granting operations at execve-time.  For example, a
      process will not be able to execute a setuid binary to change their uid
      or gid if this bit is set.  The same is true for file capabilities.
      Additionally, LSM_UNSAFE_NO_NEW_PRIVS is defined to ensure that
      LSMs respect the requested behavior.
      To determine if the NO_NEW_PRIVS bit is set, a task may call
        prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0);
      It returns 1 if set and 0 if it is not set. If any of the arguments are
      non-zero, it will return -1 and set errno to -EINVAL.
      (PR_SET_NO_NEW_PRIVS behaves similarly.)
      This functionality is desired for the proposed seccomp filter patch
      series.  By using PR_SET_NO_NEW_PRIVS, it allows a task to modify the
      system call behavior for itself and its child tasks without being
      able to impact the behavior of a more privileged task.
      Another potential use is making certain privileged operations
      unprivileged.  For example, chroot may be considered "safe" if it cannot
      affect privileged tasks.
      Note, this patch causes execve to fail when PR_SET_NO_NEW_PRIVS is
      set and AppArmor is in use.  It is fixed in a subsequent patch.
      Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarWill Drewry <wad@chromium.org>
      Acked-by: default avatarEric Paris <eparis@redhat.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      v18: updated change desc
      v17: using new define values as per 3.4
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
  24. 09 Apr, 2012 1 commit
  25. 28 Feb, 2012 1 commit
  26. 13 Feb, 2012 2 commits
  27. 09 Feb, 2012 1 commit
  28. 07 Jan, 2012 1 commit
  29. 05 Jan, 2012 5 commits
    • Eric Paris's avatar
      security: remove the security_netlink_recv hook as it is equivalent to capable() · fd778461
      Eric Paris authored
      Once upon a time netlink was not sync and we had to get the effective
      capabilities from the skb that was being received.  Today we instead get
      the capabilities from the current task.  This has rendered the entire
      purpose of the hook moot as it is now functionally equivalent to the
      capable() call.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
    • Eric Paris's avatar
      capabilities: remove all _real_ interfaces · 2920a840
      Eric Paris authored
      The name security_real_capable and security_real_capable_noaudit just don't
      make much sense to me.  Convert them to use security_capable and
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Acked-by: default avatarSerge E. Hallyn <serge.hallyn@canonical.com>
    • Eric Paris's avatar
      capabilities: introduce security_capable_noaudit · c7eba4a9
      Eric Paris authored
      Exactly like security_capable except don't audit any denials.  This is for
      places where the kernel may make decisions about what to do if a task has a
      given capability, but which failing that capability is not a sign of a
      security policy violation.  An example is checking if a task has
      CAP_SYS_ADMIN to lower it's likelyhood of being killed by the oom killer.
      This check is not a security violation if it is denied.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Acked-by: default avatarSerge E. Hallyn <serge.hallyn@canonical.com>
    • Eric Paris's avatar
      capabilities: reverse arguments to security_capable · b7e724d3
      Eric Paris authored
      security_capable takes ns, cred, cap.  But the LSM capable() hook takes
      cred, ns, cap.  The capability helper functions also take cred, ns, cap.
      Rather than flip argument order just to flip it back, leave them alone.
      Heck, this should be a little faster since argument will be in the right
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
    • Eric Paris's avatar
      capabilities: remove the task from capable LSM hook entirely · 6a9de491
      Eric Paris authored
      The capabilities framework is based around credentials, not necessarily the
      current task.  Yet we still passed the current task down into LSMs from the
      security_capable() LSM hook as if it was a meaningful portion of the security
      decision.  This patch removes the 'generic' passing of current and instead
      forces individual LSMs to use current explicitly if they think it is
      appropriate.  In our case those LSMs are SELinux and AppArmor.
      I believe the AppArmor use of current is incorrect, but that is wholely
      unrelated to this patch.  This patch does not change what AppArmor does, it
      just makes it clear in the AppArmor code that it is doing it.
      The SELinux code still uses current in it's audit message, which may also be
      wrong and needs further investigation.  Again this is NOT a change, it may
      have always been wrong, this patch just makes it clear what is happening.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
  30. 04 Jan, 2012 1 commit