1. 03 8月, 2017 1 次提交
    • S
      selinux: Generalize support for NNP/nosuid SELinux domain transitions · af63f419
      Stephen Smalley 提交于
      As systemd ramps up enabling NNP (NoNewPrivileges) for system services,
      it is increasingly breaking SELinux domain transitions for those services
      and their descendants.  systemd enables NNP not only for services whose
      unit files explicitly specify NoNewPrivileges=yes but also for services
      whose unit files specify any of the following options in combination with
      running without CAP_SYS_ADMIN (e.g. specifying User= or a
      CapabilityBoundingSet= without CAP_SYS_ADMIN): SystemCallFilter=,
      SystemCallArchitectures=, RestrictAddressFamilies=, RestrictNamespaces=,
      PrivateDevices=, ProtectKernelTunables=, ProtectKernelModules=,
      MemoryDenyWriteExecute=, or RestrictRealtime= as per the systemd.exec(5)
      man page.
      
      The end result is bad for the security of both SELinux-disabled and
      SELinux-enabled systems.  Packagers have to turn off these
      options in the unit files to preserve SELinux domain transitions.  For
      users who choose to disable SELinux, this means that they miss out on
      at least having the systemd-supported protections.  For users who keep
      SELinux enabled, they may still be missing out on some protections
      because it isn't necessarily guaranteed that the SELinux policy for
      that service provides the same protections in all cases.
      
      commit 7b0d0b40 ("selinux: Permit bounded transitions under
      NO_NEW_PRIVS or NOSUID.") allowed bounded transitions under NNP in
      order to support limited usage for sandboxing programs.  However,
      defining typebounds for all of the affected service domains
      is impractical to implement in policy, since typebounds requires us
      to ensure that each domain is allowed everything all of its descendant
      domains are allowed, and this has to be repeated for the entire chain
      of domain transitions.  There is no way to clone all allow rules from
      descendants to their ancestors in policy currently, and doing so would
      be undesirable even if it were practical, as it requires leaking
      permissions to objects and operations into ancestor domains that could
      weaken their own security in order to allow them to the descendants
      (e.g. if a descendant requires execmem permission, then so do all of
      its ancestors; if a descendant requires execute permission to a file,
      then so do all of its ancestors; if a descendant requires read to a
      symbolic link or temporary file, then so do all of its ancestors...).
      SELinux domains are intentionally not hierarchical / bounded in this
      manner normally, and making them so would undermine their protections
      and least privilege.
      
      We have long had a similar tension with SELinux transitions and nosuid
      mounts, albeit not as severe.  Users often have had to choose between
      retaining nosuid on a mount and allowing SELinux domain transitions on
      files within those mounts.  This likewise leads to unfortunate tradeoffs
      in security.
      
      Decouple NNP/nosuid from SELinux transitions, so that we don't have to
      make a choice between them. Introduce a nnp_nosuid_transition policy
      capability that enables transitions under NNP/nosuid to be based on
      a permission (nnp_transition for NNP; nosuid_transition for nosuid)
      between the old and new contexts in addition to the current support
      for bounded transitions.  Domain transitions can then be allowed in
      policy without requiring the parent to be a strict superset of all of
      its children.
      
      With this change, systemd unit files can be left unmodified from upstream.
      SELinux-disabled and SELinux-enabled users will benefit from retaining any
      of the systemd-provided protections.  SELinux policy will only need to
      be adapted to enable the new policy capability and to allow the
      new permissions between domain pairs as appropriate.
      
      NB: Allowing nnp_transition between two contexts opens up the potential
      for the old context to subvert the new context by installing seccomp
      filters before the execve.  Allowing nosuid_transition between two contexts
      opens up the potential for a context transition to occur on a file from
      an untrusted filesystem (e.g. removable media or remote filesystem).  Use
      with care.
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      af63f419
  2. 26 7月, 2017 1 次提交
  3. 21 6月, 2017 2 次提交
  4. 13 6月, 2017 1 次提交
  5. 10 6月, 2017 2 次提交
    • S
      security/selinux: allow security_sb_clone_mnt_opts to enable/disable native labeling behavior · 0b4d3452
      Scott Mayhew 提交于
      When an NFSv4 client performs a mount operation, it first mounts the
      NFSv4 root and then does path walk to the exported path and performs a
      submount on that, cloning the security mount options from the root's
      superblock to the submount's superblock in the process.
      
      Unless the NFS server has an explicit fsid=0 export with the
      "security_label" option, the NFSv4 root superblock will not have
      SBLABEL_MNT set, and neither will the submount superblock after cloning
      the security mount options.  As a result, setxattr's of security labels
      over NFSv4.2 will fail.  In a similar fashion, NFSv4.2 mounts mounted
      with the context= mount option will not show the correct labels because
      the nfs_server->caps flags of the cloned superblock will still have
      NFS_CAP_SECURITY_LABEL set.
      
      Allowing the NFSv4 client to enable or disable SECURITY_LSM_NATIVE_LABELS
      behavior will ensure that the SBLABEL_MNT flag has the correct value
      when the client traverses from an exported path without the
      "security_label" option to one with the "security_label" option and
      vice versa.  Similarly, checking to see if SECURITY_LSM_NATIVE_LABELS is
      set upon return from security_sb_clone_mnt_opts() and clearing
      NFS_CAP_SECURITY_LABEL if necessary will allow the correct labels to
      be displayed for NFSv4.2 mounts mounted with the context= mount option.
      
      Resolves: https://github.com/SELinuxProject/selinux-kernel/issues/35Signed-off-by: NScott Mayhew <smayhew@redhat.com>
      Reviewed-by: NStephen Smalley <sds@tycho.nsa.gov>
      Tested-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      0b4d3452
    • J
      selinux: use kmem_cache for ebitmap · b4958c89
      Junil Lee 提交于
      The allocated size for each ebitmap_node is 192byte by kzalloc().
      Then, ebitmap_node size is fixed, so it's possible to use only 144byte
      for each object by kmem_cache_zalloc().
      It can reduce some dynamic allocation size.
      Signed-off-by: NJunil Lee <junil0814.lee@lge.com>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      b4958c89
  6. 02 6月, 2017 1 次提交
  7. 26 5月, 2017 1 次提交
  8. 24 5月, 2017 6 次提交
  9. 23 5月, 2017 8 次提交
    • M
      selinux: Remove redundant check for unknown labeling behavior · 270e8573
      Matthias Kaehlcke 提交于
      The check is already performed in ocontext_read() when the policy is
      loaded. Removing the array also fixes the following warning when
      building with clang:
      
      security/selinux/hooks.c:338:20: error: variable 'labeling_behaviors'
          is not needed and will not be emitted
          [-Werror,-Wunneeded-internal-declaration]
      Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
      Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      270e8573
    • S
      selinux: log policy capability state when a policy is loaded · 4dc2fce3
      Stephen Smalley 提交于
      Log the state of SELinux policy capabilities when a policy is loaded.
      For each policy capability known to the kernel, log the policy capability
      name and the value set in the policy.  For policy capabilities that are
      set in the loaded policy but unknown to the kernel, log the policy
      capability index, since this is the only information presently available
      in the policy.
      
      Sample output with a policy created with a new capability defined
      that is not known to the kernel:
      SELinux:  policy capability network_peer_controls=1
      SELinux:  policy capability open_perms=1
      SELinux:  policy capability extended_socket_class=1
      SELinux:  policy capability always_check_network=0
      SELinux:  policy capability cgroup_seclabel=0
      SELinux:  unknown policy capability 5
      
      Resolves: https://github.com/SELinuxProject/selinux-kernel/issues/32Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      4dc2fce3
    • S
      selinux: do not check open permission on sockets · ccb54478
      Stephen Smalley 提交于
      open permission is currently only defined for files in the kernel
      (COMMON_FILE_PERMS rather than COMMON_FILE_SOCK_PERMS). Construction of
      an artificial test case that tries to open a socket via /proc/pid/fd will
      generate a recvfrom avc denial because recvfrom and open happen to map to
      the same permission bit in socket vs file classes.
      
      open of a socket via /proc/pid/fd is not supported by the kernel regardless
      and will ultimately return ENXIO. But we hit the permission check first and
      can thus produce these odd/misleading denials.  Omit the open check when
      operating on a socket.
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      ccb54478
    • S
      selinux: add a map permission check for mmap · 3ba4bf5f
      Stephen Smalley 提交于
      Add a map permission check on mmap so that we can distinguish memory mapped
      access (since it has different implications for revocation). When a file
      is opened and then read or written via syscalls like read(2)/write(2),
      we revalidate access on each read/write operation via
      selinux_file_permission() and therefore can revoke access if the
      process context, the file context, or the policy changes in such a
      manner that access is no longer allowed. When a file is opened and then
      memory mapped via mmap(2) and then subsequently read or written directly
      in memory, we presently have no way to revalidate or revoke access.
      The purpose of a separate map permission check on mmap(2) is to permit
      policy to prohibit memory mapping of specific files for which we need
      to ensure that every access is revalidated, particularly useful for
      scenarios where we expect the file to be relabeled at runtime in order
      to reflect state changes (e.g. cross-domain solution, assured pipeline
      without data copying).
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      3ba4bf5f
    • S
      selinux: only invoke capabilities and selinux for CAP_MAC_ADMIN checks · db59000a
      Stephen Smalley 提交于
      SELinux uses CAP_MAC_ADMIN to control the ability to get or set a raw,
      uninterpreted security context unknown to the currently loaded security
      policy. When performing these checks, we only want to perform a base
      capabilities check and a SELinux permission check.  If any other
      modules that implement a capable hook are stacked with SELinux, we do
      not want to require them to also have to authorize CAP_MAC_ADMIN,
      since it may have different implications for their security model.
      Rework the CAP_MAC_ADMIN checks within SELinux to only invoke the
      capabilities module and the SELinux permission checking.
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      db59000a
    • M
      selinux: Return an error code only as a constant in sidtab_insert() · 46be14d2
      Markus Elfring 提交于
      * Return an error code without storing it in an intermediate variable.
      
      * Delete the local variable "rc" and the jump label "out" which became
        unnecessary with this refactoring.
      Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      46be14d2
    • M
      selinux: Return directly after a failed memory allocation in policydb_index() · 62934ffb
      Markus Elfring 提交于
      Replace five goto statements (and previous variable assignments) by
      direct returns after a memory allocation failure in this function.
      Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      62934ffb
    • T
      selinux: Use task_alloc hook rather than task_create hook · a79be238
      Tetsuo Handa 提交于
      This patch is a preparation for getting rid of task_create hook because
      task_alloc hook which can do what task_create hook can do was revived.
      
      Creating a new thread is unlikely prohibited by security policy, for
      fork()/execve()/exit() is fundamental of how processes are managed in
      Unix. If a program is known to create a new thread, it is likely that
      permission to create a new thread is given to that program. Therefore,
      a situation where security_task_create() returns an error is likely that
      the program was exploited and lost control. Even if SELinux failed to
      check permission to create a thread at security_task_create(), SELinux
      can later check it at security_task_alloc(). Since the new thread is not
      yet visible from the rest of the system, nobody can do bad things using
      the new thread. What we waste will be limited to some initialization
      steps such as dup_task_struct(), copy_creds() and audit_alloc() in
      copy_process(). We can tolerate these overhead for unlikely situation.
      
      Therefore, this patch changes SELinux to use task_alloc hook rather than
      task_create hook so that we can remove task_create hook.
      Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      a79be238
  10. 27 4月, 2017 1 次提交
  11. 01 4月, 2017 1 次提交
  12. 30 3月, 2017 1 次提交
  13. 29 3月, 2017 14 次提交