On Thu, Jan 19, 2017 at 8:28 PM, Mike Frysinger <vap...@gentoo.org> wrote: > From: Mike Frysinger <vap...@chromium.org> > > 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/676357 > Signed-off-by: Mike Frysinger <vap...@chromium.org> > Acked-by: Jorge Lucangeli Obes <jorg...@chromium.org>
Yup, I think this is fine. The additional kernel code executed before the do_exit() is relatively limited, and is equivalent to leaving kill(self, SIGSEGV) exposed in a seccomp filter. Setting an RLIMIT is also sufficient to block the core generation, so really paranoid environments can still do that. The forwarded ack stands: Acked-by: Kees Cook <keesc...@chromium.org> James, can you add this to your tree? -Kees -- Kees Cook Nexus Security
