1. 17 Aug, 2017 2 commits
  2. 08 Aug, 2017 1 commit
  3. 02 Aug, 2017 1 commit
    • Stephen Smalley's avatar
      selinux: Generalize support for NNP/nosuid SELinux domain transitions · af63f419
      Stephen Smalley authored
      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: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
  4. 25 Jul, 2017 1 commit
  5. 18 Jul, 2017 1 commit
  6. 14 Jul, 2017 1 commit
  7. 12 Jul, 2017 1 commit
    • Daniel Micay's avatar
      include/linux/string.h: add the option of fortified string.h functions · 6974f0c4
      Daniel Micay authored
      This adds support for compiling with a rough equivalent to the glibc
      _FORTIFY_SOURCE=1 feature, providing compile-time and runtime buffer
      overflow checks for string.h functions when the compiler determines the
      size of the source or destination buffer at compile-time.  Unlike glibc,
      it covers buffer reads in addition to writes.
      GNU C __builtin_*_chk intrinsics are avoided because they would force a
      much more complex implementation.  They aren't designed to detect read
      overflows and offer no real benefit when using an implementation based
      on inline checks.  Inline checks don't add up to much code size and
      allow full use of the regular string intrinsics while avoiding the need
      for a bunch of _chk functions and per-arch assembly to avoid wrapper
      This detects various overflows at compile-time in various drivers and
      some non-x86 core kernel code.  There will likely be issues caught in
      regular use at runtime too.
      Future improvements left out of initial implementation for simplicity,
      as it's all quite optional and can be done incrementally:
      * Some of the fortified string functions (strncpy, strcat), don't yet
        place a limit on reads from the source based on __builtin_object_size of
        the source buffer.
      * Extending coverage to more string functions like strlcat.
      * It should be possible to optionally use __builtin_object_size(x, 1) for
        some functions (C strings) to detect intra-object overflows (like
        glibc's _FORTIFY_SOURCE=2), but for now this takes the conservative
        approach to avoid likely compatibility issues.
      * The compile-time checks should be made available via a separate config
        option which can be enabled by default (or always enabled) once enough
        time has passed to get the issues it catches fixed.
      Kees said:
       "This is great to have. While it was out-of-tree code, it would have
        blocked at least CVE-2016-3858 from being exploitable (improper size
        argument to strlcpy()). I've sent a number of fixes for
        out-of-bounds-reads that this detected upstream already"
      [arnd@arndb.de: x86: fix fortified memcpy]
        Link: http://lkml.kernel.org/r/20170627150047.660360-1-arnd@arndb.de
      [keescook@chromium.org: avoid panic() in favor of BUG()]
        Link: http://lkml.kernel.org/r/20170626235122.GA25261@beast
      [keescook@chromium.org: move from -mm, add ARCH_HAS_FORTIFY_SOURCE, tweak Kconfig help]
      Link: http://lkml.kernel.org/r/20170526095404.20439-1-danielmicay@gmail.com
      Link: http://lkml.kernel.org/r/1497903987-21002-8-git-send-email-keescook@chromium.orgSigned-off-by: default avatarDaniel Micay <danielmicay@gmail.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Daniel Axtens <dja@axtens.net>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  8. 30 Jun, 2017 2 commits
    • Kees Cook's avatar
      randstruct: Mark various structs for randomization · 3859a271
      Kees Cook authored
      This marks many critical kernel structures for randomization. These are
      structures that have been targeted in the past in security exploits, or
      contain functions pointers, pointers to function pointer tables, lists,
      workqueues, ref-counters, credentials, permissions, or are otherwise
      sensitive. This initial list was extracted from Brad Spengler/PaX Team's
      code in the last public patch of grsecurity/PaX based on my understanding
      of the code. Changes or omissions from the original code are mine and
      don't reflect the original grsecurity/PaX code.
      Left out of this list is task_struct, which requires special handling
      and will be covered in a subsequent patch.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
    • Al Viro's avatar
  9. 28 Jun, 2017 1 commit
  10. 21 Jun, 2017 16 commits
  11. 20 Jun, 2017 2 commits
    • Jeff Vander Stoep's avatar
      selinux: enable genfscon labeling for tracefs · 6a391183
      Jeff Vander Stoep authored
      In kernel version 4.1, tracefs was separated from debugfs into its
      own filesystem. Prior to this split, files in
      /sys/kernel/debug/tracing could be labeled during filesystem
      creation using genfscon or later from userspace using setxattr. This
      change re-enables support for genfscon labeling.
      Signed-off-by: default avatarJeff Vander Stoep <jeffv@google.com>
      Acked-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
    • Ingo Molnar's avatar
      sched/wait: Split out the wait_bit*() APIs from <linux/wait.h> into <linux/wait_bit.h> · 5dd43ce2
      Ingo Molnar authored
      The wait_bit*() types and APIs are mixed into wait.h, but they
      are a pretty orthogonal extension of wait-queues.
      Furthermore, only about 50 kernel files use these APIs, while
      over 1000 use the regular wait-queue functionality.
      So clean up the main wait.h by moving the wait-bit functionality
      out of it, into a separate .h and .c file:
        include/linux/wait_bit.h  for types and APIs
        kernel/sched/wait_bit.c   for the implementation
      Update all header dependencies.
      This reduces the size of wait.h rather significantly, by about 30%.
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  12. 13 Jun, 2017 1 commit
  13. 11 Jun, 2017 10 commits