On Tue, Jan 31, 2017 at 1:59 PM, Andy Lutomirski wrote:
> On Fri, Jan 27, 2017 at 1:48 PM, Kees Cook wrote:
>> On Wed, Jan 25, 2017 at 12:05 PM, Kees Cook wrote:
>>> On Tue, Jan 24, 2017 at 4:53 PM, Andrei Vagin wrote:
Hi,
One of CRIU tests fails with this patch:
https://git
On Fri, Jan 27, 2017 at 1:48 PM, Kees Cook wrote:
> On Wed, Jan 25, 2017 at 12:05 PM, Kees Cook wrote:
>> On Tue, Jan 24, 2017 at 4:53 PM, Andrei Vagin wrote:
>>> Hi,
>>>
>>> One of CRIU tests fails with this patch:
>>> https://github.com/xemul/criu/blob/master/test/zdtm/static/seccomp_filter_ts
On Fri, Jan 27, 2017 at 01:48:30PM -0800, Kees Cook wrote:
> On Wed, Jan 25, 2017 at 12:05 PM, Kees Cook wrote:
> > On Tue, Jan 24, 2017 at 4:53 PM, Andrei Vagin wrote:
> >> Hi,
> >>
> >> One of CRIU tests fails with this patch:
> >> https://github.com/xemul/criu/blob/master/test/zdtm/static/secc
On Fri, Jan 27, 2017 at 4:48 PM, Kees Cook wrote:
> For logging, I think audit needs to grow fork-tracking, and/or have a
> new "is under seccomp" test that can be exposed to auditctl. Then the
> system owner can issue either "tell me about all seccomp kills" or
> "tell me about seccomp kills in t
On Wed, Jan 25, 2017 at 12:05 PM, Kees Cook wrote:
> On Tue, Jan 24, 2017 at 4:53 PM, Andrei Vagin wrote:
>> Hi,
>>
>> One of CRIU tests fails with this patch:
>> https://github.com/xemul/criu/blob/master/test/zdtm/static/seccomp_filter_tsync.c
>>
>> Before this patch only a thread which called a
On Tue, Jan 24, 2017 at 4:53 PM, Andrei Vagin wrote:
> Hi,
>
> One of CRIU tests fails with this patch:
> https://github.com/xemul/criu/blob/master/test/zdtm/static/seccomp_filter_tsync.c
>
> Before this patch only a thread which called a "wrong" syscall is killed.
> Now a whole process is killed
thank for the testcase. i'll take a look. when i went through the code
visually, i didn't think it was killing, just suspending+resuming for the
sake of snapshotting, but i must have misread.
-mike
On Tue, Jan 24, 2017 at 2:53 PM, Andrei Vagin wrote:
> Hi,
>
> One of CRIU tests fails with this
Hi,
One of CRIU tests fails with this patch:
https://github.com/xemul/criu/blob/master/test/zdtm/static/seccomp_filter_tsync.c
Before this patch only a thread which called a "wrong" syscall is killed.
Now a whole process is killed if one of threads called a "wrong" syscall.
Before this patch onl
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
13 matches
Mail list logo
