1. 15 Jan, 2019 1 commit
    • Tycho Andersen's avatar
      seccomp: fix UAF in user-trap code · a811dc61
      Tycho Andersen authored
      On the failure path, we do an fput() of the listener fd if the filter fails
      to install (e.g. because of a TSYNC race that's lost, or if the thread is
      killed, etc.). fput() doesn't actually release the fd, it just ads it to a
      work queue. Then the thread proceeds to free the filter, even though the
      listener struct file has a reference to it.
      
      To fix this, on the failure path let's set the private data to null, so we
      know in ->release() to ignore the filter.
      
      Reported-by: syzbot+981c26489b2d1c6316ba@syzkaller.appspotmail.com
      Fixes: 6a21cc50 ("seccomp: add a return code to trap to userspace")
      Signed-off-by: default avatarTycho Andersen <tycho@tycho.ws>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarJames Morris <james.morris@microsoft.com>
      a811dc61
  2. 10 Jan, 2019 1 commit
  3. 14 Dec, 2018 1 commit
    • Tycho Andersen's avatar
      seccomp: fix poor type promotion · 319deec7
      Tycho Andersen authored
      sparse complains,
      
      kernel/seccomp.c:1172:13: warning: incorrect type in assignment (different base types)
      kernel/seccomp.c:1172:13:    expected restricted __poll_t [usertype] ret
      kernel/seccomp.c:1172:13:    got int
      kernel/seccomp.c:1173:13: warning: restricted __poll_t degrades to integer
      
      Instead of assigning this to ret, since we don't use this anywhere, let's
      just test it against 0 directly.
      Signed-off-by: default avatarTycho Andersen <tycho@tycho.ws>
      Reported-by: default avatar0day robot <lkp@intel.com>
      Fixes: 6a21cc50 ("seccomp: add a return code to trap to userspace")
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      319deec7
  4. 12 Dec, 2018 3 commits
    • Tycho Andersen's avatar
      seccomp: add a return code to trap to userspace · 6a21cc50
      Tycho Andersen authored
      This patch introduces a means for syscalls matched in seccomp to notify
      some other task that a particular filter has been triggered.
      
      The motivation for this is primarily for use with containers. For example,
      if a container does an init_module(), we obviously don't want to load this
      untrusted code, which may be compiled for the wrong version of the kernel
      anyway. Instead, we could parse the module image, figure out which module
      the container is trying to load and load it on the host.
      
      As another example, containers cannot mount() in general since various
      filesystems assume a trusted image. However, if an orchestrator knows that
      e.g. a particular block device has not been exposed to a container for
      writing, it want to allow the container to mount that block device (that
      is, handle the mount for it).
      
      This patch adds functionality that is already possible via at least two
      other means that I know about, both of which involve ptrace(): first, one
      could ptrace attach, and then iterate through syscalls via PTRACE_SYSCALL.
      Unfortunately this is slow, so a faster version would be to install a
      filter that does SECCOMP_RET_TRACE, which triggers a PTRACE_EVENT_SECCOMP.
      Since ptrace allows only one tracer, if the container runtime is that
      tracer, users inside the container (or outside) trying to debug it will not
      be able to use ptrace, which is annoying. It also means that older
      distributions based on Upstart cannot boot inside containers using ptrace,
      since upstart itself uses ptrace to monitor services while starting.
      
      The actual implementation of this is fairly small, although getting the
      synchronization right was/is slightly complex.
      
      Finally, it's worth noting that the classic seccomp TOCTOU of reading
      memory data from the task still applies here, but can be avoided with
      careful design of the userspace handler: if the userspace handler reads all
      of the task memory that is necessary before applying its security policy,
      the tracee's subsequent memory edits will not be read by the tracer.
      Signed-off-by: default avatarTycho Andersen <tycho@tycho.ws>
      CC: Kees Cook <keescook@chromium.org>
      CC: Andy Lutomirski <luto@amacapital.net>
      CC: Oleg Nesterov <oleg@redhat.com>
      CC: Eric W. Biederman <ebiederm@xmission.com>
      CC: "Serge E. Hallyn" <serge@hallyn.com>
      Acked-by: default avatarSerge Hallyn <serge@hallyn.com>
      CC: Christian Brauner <christian@brauner.io>
      CC: Tyler Hicks <tyhicks@canonical.com>
      CC: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      6a21cc50
    • Tycho Andersen's avatar
      seccomp: switch system call argument type to void * · a5662e4d
      Tycho Andersen authored
      The const qualifier causes problems for any code that wants to write to the
      third argument of the seccomp syscall, as we will do in a future patch in
      this series.
      
      The third argument to the seccomp syscall is documented as void *, so
      rather than just dropping the const, let's switch everything to use void *
      as well.
      
      I believe this is safe because of 1. the documentation above, 2. there's no
      real type information exported about syscalls anywhere besides the man
      pages.
      Signed-off-by: default avatarTycho Andersen <tycho@tycho.ws>
      CC: Kees Cook <keescook@chromium.org>
      CC: Andy Lutomirski <luto@amacapital.net>
      CC: Oleg Nesterov <oleg@redhat.com>
      CC: Eric W. Biederman <ebiederm@xmission.com>
      CC: "Serge E. Hallyn" <serge@hallyn.com>
      Acked-by: default avatarSerge Hallyn <serge@hallyn.com>
      CC: Christian Brauner <christian@brauner.io>
      CC: Tyler Hicks <tyhicks@canonical.com>
      CC: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      a5662e4d
    • Tycho Andersen's avatar
      seccomp: hoist struct seccomp_data recalculation higher · db511391
      Tycho Andersen authored
      In the next patch, we're going to use the sd pointer passed to
      __seccomp_filter() as the data to pass to userspace. Except that in some
      cases (__seccomp_filter(SECCOMP_RET_TRACE), emulate_vsyscall(), every time
      seccomp is inovked on power, etc.) the sd pointer will be NULL in order to
      force seccomp to recompute the register data. Previously this recomputation
      happened one level lower, in seccomp_run_filters(); this patch just moves
      it up a level higher to __seccomp_filter().
      
      Thanks Oleg for spotting this.
      Signed-off-by: default avatarTycho Andersen <tycho@tycho.ws>
      CC: Kees Cook <keescook@chromium.org>
      CC: Andy Lutomirski <luto@amacapital.net>
      CC: Oleg Nesterov <oleg@redhat.com>
      CC: Eric W. Biederman <ebiederm@xmission.com>
      CC: "Serge E. Hallyn" <serge@hallyn.com>
      Acked-by: default avatarSerge Hallyn <serge@hallyn.com>
      CC: Christian Brauner <christian@brauner.io>
      CC: Tyler Hicks <tyhicks@canonical.com>
      CC: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      db511391
  5. 03 Oct, 2018 1 commit
    • Eric W. Biederman's avatar
      signal: Distinguish between kernel_siginfo and siginfo · ae7795bc
      Eric W. Biederman authored
      Linus recently observed that if we did not worry about the padding
      member in struct siginfo it is only about 48 bytes, and 48 bytes is
      much nicer than 128 bytes for allocating on the stack and copying
      around in the kernel.
      
      The obvious thing of only adding the padding when userspace is
      including siginfo.h won't work as there are sigframe definitions in
      the kernel that embed struct siginfo.
      
      So split siginfo in two; kernel_siginfo and siginfo.  Keeping the
      traditional name for the userspace definition.  While the version that
      is used internally to the kernel and ultimately will not be padded to
      128 bytes is called kernel_siginfo.
      
      The definition of struct kernel_siginfo I have put in include/signal_types.h
      
      A set of buildtime checks has been added to verify the two structures have
      the same field offsets.
      
      To make it easy to verify the change kernel_siginfo retains the same
      size as siginfo.  The reduction in size comes in a following change.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      ae7795bc
  6. 06 Sep, 2018 1 commit
  7. 08 May, 2018 4 commits
    • Tyler Hicks's avatar
      seccomp: Don't special case audited processes when logging · 326bee02
      Tyler Hicks authored
      Seccomp logging for "handled" actions such as RET_TRAP, RET_TRACE, or
      RET_ERRNO can be very noisy for processes that are being audited. This
      patch modifies the seccomp logging behavior to treat processes that are
      being inspected via the audit subsystem the same as processes that
      aren't under inspection. Handled actions will no longer be logged just
      because the process is being inspected. Since v4.14, applications have
      the ability to request logging of handled actions by using the
      SECCOMP_FILTER_FLAG_LOG flag when loading seccomp filters.
      
      With this patch, the logic for deciding if an action will be logged is:
      
        if action == RET_ALLOW:
          do not log
        else if action not in actions_logged:
          do not log
        else if action == RET_KILL:
          log
        else if action == RET_LOG:
          log
        else if filter-requests-logging:
          log
        else:
          do not log
      Reported-by: default avatarSteve Grubb <sgrubb@redhat.com>
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      326bee02
    • Tyler Hicks's avatar
      seccomp: Audit attempts to modify the actions_logged sysctl · ea6eca77
      Tyler Hicks authored
      The decision to log a seccomp action will always be subject to the
      value of the kernel.seccomp.actions_logged sysctl, even for processes
      that are being inspected via the audit subsystem, in an upcoming patch.
      Therefore, we need to emit an audit record on attempts at writing to the
      actions_logged sysctl when auditing is enabled.
      
      This patch updates the write handler for the actions_logged sysctl to
      emit an audit record on attempts to write to the sysctl. Successful
      writes to the sysctl will result in a record that includes a normalized
      list of logged actions in the "actions" field and a "res" field equal to
      1. Unsuccessful writes to the sysctl will result in a record that
      doesn't include the "actions" field and has a "res" field equal to 0.
      
      Not all unsuccessful writes to the sysctl are audited. For example, an
      audit record will not be emitted if an unprivileged process attempts to
      open the sysctl file for reading since that access control check is not
      part of the sysctl's write handler.
      
      Below are some example audit records when writing various strings to the
      actions_logged sysctl.
      
      Writing "not-a-real-action", when the kernel.seccomp.actions_logged
      sysctl previously was "kill_process kill_thread trap errno trace log",
      emits this audit record:
      
       type=CONFIG_CHANGE msg=audit(1525392371.454:120): op=seccomp-logging
       actions=? old-actions=kill_process,kill_thread,trap,errno,trace,log
       res=0
      
      If you then write "kill_process kill_thread errno trace log", this audit
      record is emitted:
      
       type=CONFIG_CHANGE msg=audit(1525392401.645:126): op=seccomp-logging
       actions=kill_process,kill_thread,errno,trace,log
       old-actions=kill_process,kill_thread,trap,errno,trace,log res=1
      
      If you then write "log log errno trace kill_process kill_thread", which
      is unordered and contains the log action twice, it results in the same
      actions value as the previous record:
      
       type=CONFIG_CHANGE msg=audit(1525392436.354:132): op=seccomp-logging
       actions=kill_process,kill_thread,errno,trace,log
       old-actions=kill_process,kill_thread,errno,trace,log res=1
      
      If you then write an empty string to the sysctl, this audit record is
      emitted:
      
       type=CONFIG_CHANGE msg=audit(1525392494.413:138): op=seccomp-logging
       actions=(none) old-actions=kill_process,kill_thread,errno,trace,log
       res=1
      
      No audit records are generated when reading the actions_logged sysctl.
      Suggested-by: default avatarSteve Grubb <sgrubb@redhat.com>
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      ea6eca77
    • Tyler Hicks's avatar
      seccomp: Configurable separator for the actions_logged string · beb44aca
      Tyler Hicks authored
      The function that converts a bitmask of seccomp actions that are
      allowed to be logged is currently only used for constructing the display
      string for the kernel.seccomp.actions_logged sysctl. That string wants a
      space character to be used for the separator between actions.
      
      A future patch will make use of the same function for building a string
      that will be sent to the audit subsystem for tracking modifications to
      the kernel.seccomp.actions_logged sysctl. That string will need to use a
      comma as a separator. This patch allows the separator character to be
      configurable to meet both needs.
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      beb44aca
    • Tyler Hicks's avatar
      seccomp: Separate read and write code for actions_logged sysctl · d013db02
      Tyler Hicks authored
      Break the read and write paths of the kernel.seccomp.actions_logged
      sysctl into separate functions to maintain readability. An upcoming
      change will need to audit writes, but not reads, of this sysctl which
      would introduce too many conditional code paths on whether or not the
      'write' parameter evaluates to true.
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      d013db02
  8. 04 May, 2018 3 commits
  9. 03 May, 2018 1 commit
  10. 22 Feb, 2018 1 commit
  11. 23 Jan, 2018 1 commit
  12. 17 Dec, 2017 1 commit
  13. 28 Nov, 2017 2 commits
  14. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  15. 24 Oct, 2017 1 commit
  16. 10 Oct, 2017 1 commit
  17. 28 Sep, 2017 1 commit
  18. 14 Aug, 2017 9 commits
    • Kees Cook's avatar
      seccomp: Implement SECCOMP_RET_KILL_PROCESS action · 0466bdb9
      Kees Cook authored
      Right now, SECCOMP_RET_KILL_THREAD (neé SECCOMP_RET_KILL) kills the
      current thread. There have been a few requests for this to kill the entire
      process (the thread group). This cannot be just changed (discovered when
      adding coredump support since coredumping kills the entire process)
      because there are userspace programs depending on the thread-kill
      behavior.
      
      Instead, implement SECCOMP_RET_KILL_PROCESS, which is 0x80000000, and can
      be processed as "-1" by the kernel, below the existing RET_KILL that is
      ABI-set to "0". For userspace, SECCOMP_RET_ACTION_FULL is added to expand
      the mask to the signed bit. Old userspace using the SECCOMP_RET_ACTION
      mask will see SECCOMP_RET_KILL_PROCESS as 0 still, but this would only
      be visible when examining the siginfo in a core dump from a RET_KILL_*,
      where it will think it was thread-killed instead of process-killed.
      
      Attempts to introduce this behavior via other ways (filter flags,
      seccomp struct flags, masked RET_DATA bits) all come with weird
      side-effects and baggage. This change preserves the central behavioral
      expectations of the seccomp filter engine without putting too great
      a burden on changes needed in userspace to use the new action.
      
      The new action is discoverable by userspace through either the new
      actions_avail sysctl or through the SECCOMP_GET_ACTION_AVAIL seccomp
      operation. If used without checking for availability, old kernels
      will treat RET_KILL_PROCESS as RET_KILL_THREAD (since the old mask
      will produce RET_KILL_THREAD).
      
      Cc: Paul Moore <paul@paul-moore.com>
      Cc: Fabricio Voznika <fvoznika@google.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      0466bdb9
    • Kees Cook's avatar
      seccomp: Introduce SECCOMP_RET_KILL_PROCESS · 4d3b0b05
      Kees Cook authored
      This introduces the BPF return value for SECCOMP_RET_KILL_PROCESS to kill
      an entire process. This cannot yet be reached by seccomp, but it changes
      the default-kill behavior (for unknown return values) from kill-thread to
      kill-process.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      4d3b0b05
    • Kees Cook's avatar
      seccomp: Rename SECCOMP_RET_KILL to SECCOMP_RET_KILL_THREAD · fd76875c
      Kees Cook authored
      In preparation for adding SECCOMP_RET_KILL_PROCESS, rename SECCOMP_RET_KILL
      to the more accurate SECCOMP_RET_KILL_THREAD.
      
      The existing selftest values are intentionally left as SECCOMP_RET_KILL
      just to be sure we're exercising the alias.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      fd76875c
    • Tyler Hicks's avatar
      seccomp: Action to log before allowing · 59f5cf44
      Tyler Hicks authored
      Add a new action, SECCOMP_RET_LOG, that logs a syscall before allowing
      the syscall. At the implementation level, this action is identical to
      the existing SECCOMP_RET_ALLOW action. However, it can be very useful when
      initially developing a seccomp filter for an application. The developer
      can set the default action to be SECCOMP_RET_LOG, maybe mark any
      obviously needed syscalls with SECCOMP_RET_ALLOW, and then put the
      application through its paces. A list of syscalls that triggered the
      default action (SECCOMP_RET_LOG) can be easily gleaned from the logs and
      that list can be used to build the syscall whitelist. Finally, the
      developer can change the default action to the desired value.
      
      This provides a more friendly experience than seeing the application get
      killed, then updating the filter and rebuilding the app, seeing the
      application get killed due to a different syscall, then updating the
      filter and rebuilding the app, etc.
      
      The functionality is similar to what's supported by the various LSMs.
      SELinux has permissive mode, AppArmor has complain mode, SMACK has
      bring-up mode, etc.
      
      SECCOMP_RET_LOG is given a lower value than SECCOMP_RET_ALLOW as allow
      while logging is slightly more restrictive than quietly allowing.
      
      Unfortunately, the tests added for SECCOMP_RET_LOG are not capable of
      inspecting the audit log to verify that the syscall was logged.
      
      With this patch, the logic for deciding if an action will be logged is:
      
      if action == RET_ALLOW:
        do not log
      else if action == RET_KILL && RET_KILL in actions_logged:
        log
      else if action == RET_LOG && RET_LOG in actions_logged:
        log
      else if filter-requests-logging && action in actions_logged:
        log
      else if audit_enabled && process-is-being-audited:
        log
      else:
        do not log
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      59f5cf44
    • Tyler Hicks's avatar
      seccomp: Filter flag to log all actions except SECCOMP_RET_ALLOW · e66a3997
      Tyler Hicks authored
      Add a new filter flag, SECCOMP_FILTER_FLAG_LOG, that enables logging for
      all actions except for SECCOMP_RET_ALLOW for the given filter.
      
      SECCOMP_RET_KILL actions are always logged, when "kill" is in the
      actions_logged sysctl, and SECCOMP_RET_ALLOW actions are never logged,
      regardless of this flag.
      
      This flag can be used to create noisy filters that result in all
      non-allowed actions to be logged. A process may have one noisy filter,
      which is loaded with this flag, as well as a quiet filter that's not
      loaded with this flag. This allows for the actions in a set of filters
      to be selectively conveyed to the admin.
      
      Since a system could have a large number of allocated seccomp_filter
      structs, struct packing was taken in consideration. On 64 bit x86, the
      new log member takes up one byte of an existing four byte hole in the
      struct. On 32 bit x86, the new log member creates a new four byte hole
      (unavoidable) and consumes one of those bytes.
      
      Unfortunately, the tests added for SECCOMP_FILTER_FLAG_LOG are not
      capable of inspecting the audit log to verify that the actions taken in
      the filter were logged.
      
      With this patch, the logic for deciding if an action will be logged is:
      
      if action == RET_ALLOW:
        do not log
      else if action == RET_KILL && RET_KILL in actions_logged:
        log
      else if filter-requests-logging && action in actions_logged:
        log
      else if audit_enabled && process-is-being-audited:
        log
      else:
        do not log
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      e66a3997
    • Tyler Hicks's avatar
      seccomp: Sysctl to configure actions that are allowed to be logged · 0ddec0fc
      Tyler Hicks authored
      Adminstrators can write to this sysctl to set the seccomp actions that
      are allowed to be logged. Any actions not found in this sysctl will not
      be logged.
      
      For example, all SECCOMP_RET_KILL, SECCOMP_RET_TRAP, and
      SECCOMP_RET_ERRNO actions would be loggable if "kill trap errno" were
      written to the sysctl. SECCOMP_RET_TRACE actions would not be logged
      since its string representation ("trace") wasn't present in the sysctl
      value.
      
      The path to the sysctl is:
      
       /proc/sys/kernel/seccomp/actions_logged
      
      The actions_avail sysctl can be read to discover the valid action names
      that can be written to the actions_logged sysctl with the exception of
      "allow". SECCOMP_RET_ALLOW actions cannot be configured for logging.
      
      The default setting for the sysctl is to allow all actions to be logged
      except SECCOMP_RET_ALLOW. While only SECCOMP_RET_KILL actions are
      currently logged, an upcoming patch will allow applications to request
      additional actions to be logged.
      
      There's one important exception to this sysctl. If a task is
      specifically being audited, meaning that an audit context has been
      allocated for the task, seccomp will log all actions other than
      SECCOMP_RET_ALLOW despite the value of actions_logged. This exception
      preserves the existing auditing behavior of tasks with an allocated
      audit context.
      
      With this patch, the logic for deciding if an action will be logged is:
      
      if action == RET_ALLOW:
        do not log
      else if action == RET_KILL && RET_KILL in actions_logged:
        log
      else if audit_enabled && task-is-being-audited:
        log
      else:
        do not log
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      0ddec0fc
    • Tyler Hicks's avatar
      seccomp: Operation for checking if an action is available · d612b1fd
      Tyler Hicks authored
      Userspace code that needs to check if the kernel supports a given action
      may not be able to use the /proc/sys/kernel/seccomp/actions_avail
      sysctl. The process may be running in a sandbox and, therefore,
      sufficient filesystem access may not be available. This patch adds an
      operation to the seccomp(2) syscall that allows userspace code to ask
      the kernel if a given action is available.
      
      If the action is supported by the kernel, 0 is returned. If the action
      is not supported by the kernel, -1 is returned with errno set to
      -EOPNOTSUPP. If this check is attempted on a kernel that doesn't support
      this new operation, -1 is returned with errno set to -EINVAL meaning
      that userspace code will have the ability to differentiate between the
      two error cases.
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Suggested-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      d612b1fd
    • Tyler Hicks's avatar
      seccomp: Sysctl to display available actions · 8e5f1ad1
      Tyler Hicks authored
      This patch creates a read-only sysctl containing an ordered list of
      seccomp actions that the kernel supports. The ordering, from left to
      right, is the lowest action value (kill) to the highest action value
      (allow). Currently, a read of the sysctl file would return "kill trap
      errno trace allow". The contents of this sysctl file can be useful for
      userspace code as well as the system administrator.
      
      The path to the sysctl is:
      
        /proc/sys/kernel/seccomp/actions_avail
      
      libseccomp and other userspace code can easily determine which actions
      the current kernel supports. The set of actions supported by the current
      kernel may be different than the set of action macros found in kernel
      headers that were installed where the userspace code was built.
      
      In addition, this sysctl will allow system administrators to know which
      actions are supported by the kernel and make it easier to configure
      exactly what seccomp logs through the audit subsystem. Support for this
      level of logging configuration will come in a future patch.
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      8e5f1ad1
    • Kees Cook's avatar
      seccomp: Provide matching filter for introspection · deb4de8b
      Kees Cook authored
      Both the upcoming logging improvements and changes to RET_KILL will need
      to know which filter a given seccomp return value originated from. In
      order to delay logic processing of result until after the seccomp loop,
      this adds a single pointer assignment on matches. This will allow both
      log and RET_KILL logic to work off the filter rather than doing more
      expensive tests inside the time-critical run_filters loop.
      
      Running tight cycles of getpid() with filters attached shows no measurable
      difference in speed.
      Suggested-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarTyler Hicks <tyhicks@canonical.com>
      deb4de8b
  19. 26 Jun, 2017 2 commits
  20. 02 Mar, 2017 1 commit
  21. 22 Feb, 2017 1 commit
  22. 23 Jan, 2017 1 commit
    • Mike Frysinger's avatar
      seccomp: dump core when using SECCOMP_RET_KILL · b25e6716
      Mike Frysinger authored
      The SECCOMP_RET_KILL mode is documented as immediately killing the
      process as if a SIGSYS had been sent and not caught (similar to a
      SIGKILL).  However, a SIGSYS is documented as triggering a coredump
      which does not happen today.
      
      This has the advantage of being able to more easily debug a process
      that fails a seccomp filter.  Today, most apps need to recompile and
      change their filter in order to get detailed info out, or manually run
      things through strace, or enable detailed kernel auditing.  Now we get
      coredumps that fit into existing system-wide crash reporting setups.
      
      From a security pov, this shouldn't be a problem.  Unhandled signals
      can already be sent externally which trigger a coredump independent of
      the status of the seccomp filter.  The act of dumping core itself does
      not cause change in execution of the program.
      
      URL: https://crbug.com/676357Signed-off-by: default avatarMike Frysinger <vapier@chromium.org>
      Acked-by: default avatarJorge Lucangeli Obes <jorgelo@chromium.org>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      b25e6716
  23. 28 Nov, 2016 1 commit