On Mon, 23 Jan 2017, Mike Frysinger wrote:
> On Sun, Jan 22, 2017 at 4:10 PM, James Morris wrote:
> > On Fri, 20 Jan 2017, Kees Cook wrote:
> > > Yup, I think this is fine. The additional kernel code executed before
> > > the do_exit() is relatively limited, and is equivalent to leaving
> > > kill
On Sun, Jan 22, 2017 at 4:10 PM, James Morris wrote:
> On Fri, 20 Jan 2017, Kees Cook wrote:
> > 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 a
On Fri, 20 Jan 2017, Kees Cook wrote:
> 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,
On Thu, Jan 19, 2017 at 8:28 PM, Mike Frysinger wrote:
> From: 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 do
From: 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
5 matches
Mail list logo