1. 27 1月, 2017 1 次提交
  2. 24 1月, 2017 10 次提交
  3. 23 1月, 2017 1 次提交
    • M
      seccomp: dump core when using SECCOMP_RET_KILL · b25e6716
      Mike Frysinger 提交于
      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: NMike Frysinger <vapier@chromium.org>
      Acked-by: NJorge Lucangeli Obes <jorgelo@chromium.org>
      Acked-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      b25e6716
  4. 19 1月, 2017 1 次提交
  5. 17 1月, 2017 1 次提交
  6. 16 1月, 2017 26 次提交