From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Limiting SECCOMP audit events Date: Wed, 13 Dec 2017 18:58:46 -0500 Message-ID: <58203247.sCqcla2mis@x2> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3315810385792112238==" Return-path: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Linux Audit List-Id: linux-audit@redhat.com This is a multi-part message in MIME format. --===============3315810385792112238== Content-Type: multipart/alternative; boundary="nextPart4289593.71cxdu7Dxe" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart4289593.71cxdu7Dxe Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hello, Over the last month, the amount of seccomp events in audit logs is sky-rocketing. I have over a million events in the last 2 days. Most of this is generated by firefox and qt webkit. I am wondering if the audit package should ship a file for /usr/lib/sysctl.d/60-auditd.conf wherein it has kernel.seccomp.actions_logged = kill_process kill_thread errno Also, has anyone verified this sysctl is filtering audit events? Even with the above, I have over a million events on a 4.14.3 kernel. Firefox alone is generating over 50,000 events per hour. Thanks, -Steve --nextPart4289593.71cxdu7Dxe Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

Hello,

 

Over the last month, the amount of seccomp events in audit logs is sky-rocketing. I have over a million events in the last 2 days. Most of this is generated by firefox and qt webkit.

 

I am wondering if the audit package should ship a file for

 

/usr/lib/sysctl.d/60-auditd.conf

 

wherein it has

 

kernel.seccomp.actions_logged = kill_process kill_thread errno

 

Also, has anyone verified this sysctl is filtering audit events? Even with the above, I have over a million events on a 4.14.3 kernel. Firefox alone is generating over 50,000 events per hour.

 

Thanks,

-Steve

--nextPart4289593.71cxdu7Dxe-- --===============3315810385792112238== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============3315810385792112238==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: Limiting SECCOMP audit events Date: Wed, 13 Dec 2017 16:16:47 -0800 Message-ID: References: <58203247.sCqcla2mis@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx01.extmail.prod.ext.phx2.redhat.com [10.5.110.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 086F860C90 for ; Thu, 14 Dec 2017 00:16:50 +0000 (UTC) Received: from mail-vk0-f41.google.com (mail-vk0-f41.google.com [209.85.213.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5AAC7793EC for ; Thu, 14 Dec 2017 00:16:49 +0000 (UTC) Received: by mail-vk0-f41.google.com with SMTP id f199so2548241vka.8 for ; Wed, 13 Dec 2017 16:16:49 -0800 (PST) In-Reply-To: <58203247.sCqcla2mis@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: Linux Audit List-Id: linux-audit@redhat.com On Wed, Dec 13, 2017 at 3:58 PM, Steve Grubb wrote: > Hello, > > Over the last month, the amount of seccomp events in audit logs is > sky-rocketing. I have over a million events in the last 2 days. Most of this > is generated by firefox and qt webkit. > > I am wondering if the audit package should ship a file for > > /usr/lib/sysctl.d/60-auditd.conf > > wherein it has > > kernel.seccomp.actions_logged = kill_process kill_thread errno > > Also, has anyone verified this sysctl is filtering audit events? Even with > the above, I have over a million events on a 4.14.3 kernel. Firefox alone is > generating over 50,000 events per hour. I don't think you'd want to log errno -- AIUI, that's used regularly by a lot of seccomp policy. -Kees -- Kees Cook Pixel Security From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Limiting SECCOMP audit events Date: Wed, 13 Dec 2017 19:31:44 -0500 Message-ID: <2483555.uM3AbUoQxj@x2> References: <58203247.sCqcla2mis@x2> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5850651208211452881==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Kees Cook Cc: Linux Audit List-Id: linux-audit@redhat.com This is a multi-part message in MIME format. --===============5850651208211452881== Content-Type: multipart/alternative; boundary="nextPart9118612.eFxMmO8GZk" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart9118612.eFxMmO8GZk Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Wednesday, December 13, 2017 7:16:47 PM EST Kees Cook wrote: > On Wed, Dec 13, 2017 at 3:58 PM, Steve Grubb wrote: > > Hello, > > > > Over the last month, the amount of seccomp events in audit logs is > > sky-rocketing. I have over a million events in the last 2 days. Most of > > this is generated by firefox and qt webkit. > > > > I am wondering if the audit package should ship a file for > > > > /usr/lib/sysctl.d/60-auditd.conf > > > > wherein it has > > > > kernel.seccomp.actions_logged = kill_process kill_thread errno > > > > Also, has anyone verified this sysctl is filtering audit events? Even with > > the above, I have over a million events on a 4.14.3 kernel. Firefox alone > > is generating over 50,000 events per hour. > > I don't think you'd want to log errno -- AIUI, that's used regularly > by a lot of seccomp policy. I'm not seeing any reporting errno. The ones reporting trap are coming in over 50,000 per hour. I don't think the filter is working. [root@x2 ~]# cat /proc/sys/kernel/seccomp/actions_logged kill_process kill_thread errno [root@x2 ~]# date Wed Dec 13 19:24:40 EST 2017 [root@x2 ~]# ausearch --start 19:24:40 -m seccomp --raw | aureport --event -- summary -i Event Summary Report ====================== total type ====================== 170 SECCOMP In the time it took to type the command 170 seccomp events were recorded from firefox. [root@x2 ~]# ausearch --start 19:24:40 -m seccomp --just-one -i ---- node=x2 type=SECCOMP msg=audit(12/13/2017 19:24:56.454:199666) : auid=sgrubb uid=sgrubb gid=sgrubb ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3394 comm=Web Content exe=/usr/lib64/firefox/firefox sig=SIG0 arch=x86_64 syscall=stat compat=0 ip=0x7f909c828635 code=trap ^^ trap. With the sheer amount of events being recorded, I think it's necessary to add a sysctl file to systems to suppress the logging. Especially when you consider that systemd-journal also gratuitously grabs audit logs and sends them to rsyslog. -Steve --nextPart9118612.eFxMmO8GZk Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

On Wednesday, December 13, 2017 7:16:47 PM EST Kees Cook wrote:

> On Wed, Dec 13, 2017 at 3:58 PM, Steve Grubb <sgrubb@redhat.com> wrote:

> > Hello,

> >

> > Over the last month, the amount of seccomp events in audit logs is

> > sky-rocketing. I have over a million events in the last 2 days. Most of

> > this is generated by firefox and qt webkit.

> >

> > I am wondering if the audit package should ship a file for

> >

> > /usr/lib/sysctl.d/60-auditd.conf

> >

> > wherein it has

> >

> > kernel.seccomp.actions_logged = kill_process kill_thread errno

> >

> > Also, has anyone verified this sysctl is filtering audit events? Even with

> > the above, I have over a million events on a 4.14.3 kernel. Firefox alone

> > is generating over 50,000 events per hour.

>

> I don't think you'd want to log errno -- AIUI, that's used regularly

> by a lot of seccomp policy.

 

I'm not seeing any reporting errno. The ones reporting trap are coming in over 50,000 per hour. I don't think the filter is working.

 

[root@x2 ~]# cat /proc/sys/kernel/seccomp/actions_logged

kill_process kill_thread errno

[root@x2 ~]# date

Wed Dec 13 19:24:40 EST 2017

[root@x2 ~]# ausearch --start 19:24:40 -m seccomp --raw | aureport --event --summary -i

 

Event Summary Report

======================

total type

======================

170 SECCOMP

 

In the time it took to type the command 170 seccomp events were recorded from firefox.

 

[root@x2 ~]# ausearch --start 19:24:40 -m seccomp --just-one -i

----

node=x2 type=SECCOMP msg=audit(12/13/2017 19:24:56.454:199666) : auid=sgrubb uid=sgrubb gid=sgrubb ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3394 comm=Web Content exe=/usr/lib64/firefox/firefox sig=SIG0 arch=x86_64 syscall=stat compat=0 ip=0x7f909c828635 code=trap

 

^^ trap. With the sheer amount of events being recorded, I think it's necessary to add a sysctl file to systems to suppress the logging. Especially when you consider that systemd-journal also gratuitously grabs audit logs and sends them to rsyslog.

 

-Steve

--nextPart9118612.eFxMmO8GZk-- --===============5850651208211452881== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============5850651208211452881==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: Limiting SECCOMP audit events Date: Wed, 13 Dec 2017 20:43:38 -0500 Message-ID: References: <58203247.sCqcla2mis@x2> <2483555.uM3AbUoQxj@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx08.extmail.prod.ext.phx2.redhat.com [10.5.110.32]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F295217560 for ; Thu, 14 Dec 2017 01:43:42 +0000 (UTC) Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BF199C0587CE for ; Thu, 14 Dec 2017 01:43:40 +0000 (UTC) Received: by mail-lf0-f44.google.com with SMTP id f18so4812995lfg.8 for ; Wed, 13 Dec 2017 17:43:40 -0800 (PST) In-Reply-To: <2483555.uM3AbUoQxj@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: Linux Audit List-Id: linux-audit@redhat.com On Wed, Dec 13, 2017 at 7:31 PM, Steve Grubb wrote: > On Wednesday, December 13, 2017 7:16:47 PM EST Kees Cook wrote: >> On Wed, Dec 13, 2017 at 3:58 PM, Steve Grubb wrote: >> > Hello, >> > >> > Over the last month, the amount of seccomp events in audit logs is >> > sky-rocketing. I have over a million events in the last 2 days. Most of >> > this is generated by firefox and qt webkit. >> > >> > I am wondering if the audit package should ship a file for >> > >> > /usr/lib/sysctl.d/60-auditd.conf >> > >> > wherein it has >> > >> > kernel.seccomp.actions_logged = kill_process kill_thread errno >> > >> > Also, has anyone verified this sysctl is filtering audit events? Even >> > with >> > the above, I have over a million events on a 4.14.3 kernel. Firefox >> > alone >> > is generating over 50,000 events per hour. >> >> I don't think you'd want to log errno -- AIUI, that's used regularly >> by a lot of seccomp policy. > > I'm not seeing any reporting errno. The ones reporting trap are coming in > over 50,000 per hour. I don't think the filter is working. > > [root@x2 ~]# cat /proc/sys/kernel/seccomp/actions_logged > kill_process kill_thread errno > [root@x2 ~]# date > Wed Dec 13 19:24:40 EST 2017 > [root@x2 ~]# ausearch --start 19:24:40 -m seccomp --raw | aureport --event > --summary -i > Event Summary Report > ====================== > total type > ====================== > 170 SECCOMP > > In the time it took to type the command 170 seccomp events were recorded > from firefox. > > [root@x2 ~]# ausearch --start 19:24:40 -m seccomp --just-one -i > ---- > node=x2 type=SECCOMP msg=audit(12/13/2017 19:24:56.454:199666) : auid=sgrubb > uid=sgrubb gid=sgrubb ses=3 > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3394 comm=Web > Content exe=/usr/lib64/firefox/firefox sig=SIG0 arch=x86_64 syscall=stat > compat=0 ip=0x7f909c828635 code=trap > ^^ trap. With the sheer amount of events being recorded, I think it's > necessary to add a sysctl file to systems to suppress the logging. > Especially when you consider that systemd-journal also gratuitously grabs > audit logs and sends them to rsyslog. Looking at the kernel code, it looks like the actions_logged knob isn't really intended to filter/drop seccomp events, but rather force seccomp events to be loggged. Look at seccomp_log() to see what I mean; there is still a call to audit_seccomp() at the end. -- paul moore www.paul-moore.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Limiting SECCOMP audit events Date: Wed, 13 Dec 2017 22:30:21 -0500 Message-ID: <17198747.0Wk1AduiP0@x2> References: <58203247.sCqcla2mis@x2> <2483555.uM3AbUoQxj@x2> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5574989825683947579==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Paul Moore Cc: Linux Audit List-Id: linux-audit@redhat.com This is a multi-part message in MIME format. --===============5574989825683947579== Content-Type: multipart/alternative; boundary="nextPart3175413.1ar6XzAcRI" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart3175413.1ar6XzAcRI Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Wednesday, December 13, 2017 8:43:38 PM EST Paul Moore wrote: > On Wed, Dec 13, 2017 at 7:31 PM, Steve Grubb wrote: > > On Wednesday, December 13, 2017 7:16:47 PM EST Kees Cook wrote: > >> On Wed, Dec 13, 2017 at 3:58 PM, Steve Grubb wrote: > >> > Hello, > >> > > >> > Over the last month, the amount of seccomp events in audit logs is > >> > sky-rocketing. I have over a million events in the last 2 days. Most of > >> > this is generated by firefox and qt webkit. > >> > > >> > I am wondering if the audit package should ship a file for > >> > > >> > /usr/lib/sysctl.d/60-auditd.conf > >> > > >> > wherein it has > >> > > >> > kernel.seccomp.actions_logged = kill_process kill_thread errno > >> > > >> > Also, has anyone verified this sysctl is filtering audit events? Even > >> > with > >> > the above, I have over a million events on a 4.14.3 kernel. Firefox > >> > alone > >> > is generating over 50,000 events per hour. > >> > >> I don't think you'd want to log errno -- AIUI, that's used regularly > >> by a lot of seccomp policy. > > > > I'm not seeing any reporting errno. The ones reporting trap are coming in > > over 50,000 per hour. I don't think the filter is working. > > > > [root@x2 ~]# cat /proc/sys/kernel/seccomp/actions_logged > > kill_process kill_thread errno > > [root@x2 ~]# date > > Wed Dec 13 19:24:40 EST 2017 > > [root@x2 ~]# ausearch --start 19:24:40 -m seccomp --raw | aureport --event > > --summary -i > > Event Summary Report > > ====================== > > total type > > ====================== > > 170 SECCOMP > > > > In the time it took to type the command 170 seccomp events were recorded > > from firefox. > > > > [root@x2 ~]# ausearch --start 19:24:40 -m seccomp --just-one -i > > ---- > > node=x2 type=SECCOMP msg=audit(12/13/2017 19:24:56.454:199666) : > > auid=sgrubb uid=sgrubb gid=sgrubb ses=3 > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3394 > > comm=Web Content exe=/usr/lib64/firefox/firefox sig=SIG0 arch=x86_64 > > syscall=stat compat=0 ip=0x7f909c828635 code=trap > > ^^ trap. With the sheer amount of events being recorded, I think it's > > necessary to add a sysctl file to systems to suppress the logging. > > Especially when you consider that systemd-journal also gratuitously grabs > > audit logs and sends them to rsyslog. > > Looking at the kernel code, it looks like the actions_logged knob > isn't really intended to filter/drop seccomp events, That's unfortunate. I thought this was a way to suppress generation of events. We have a requirement that audit events be selective by the administrator. We need a knob to drop some events. I guess, the only knob right now is the exclude filter. That is probably too course. > but rather force seccomp events to be loggged. Look at seccomp_log() to see > what I mean; there is still a call to audit_seccomp() at the end. Hmm. What do we do? I have more than a million seccomp events in 2 days. I'm getting 14 events a second for seccomp just using my system. It's flooding everything. I mean maybe the firefox and webkit people meant well using seccomp, but how does a normal user get control back of their logs? Thanks, -Steve --nextPart3175413.1ar6XzAcRI Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

On Wednesday, December 13, 2017 8:43:38 PM EST Paul Moore wrote:

> On Wed, Dec 13, 2017 at 7:31 PM, Steve Grubb <sgrubb@redhat.com> wrote:

> > On Wednesday, December 13, 2017 7:16:47 PM EST Kees Cook wrote:

> >> On Wed, Dec 13, 2017 at 3:58 PM, Steve Grubb <sgrubb@redhat.com> wrote:

> >> > Hello,

> >> >

> >> > Over the last month, the amount of seccomp events in audit logs is

> >> > sky-rocketing. I have over a million events in the last 2 days. Most of

> >> > this is generated by firefox and qt webkit.

> >> >

> >> > I am wondering if the audit package should ship a file for

> >> >

> >> > /usr/lib/sysctl.d/60-auditd.conf

> >> >

> >> > wherein it has

> >> >

> >> > kernel.seccomp.actions_logged = kill_process kill_thread errno

> >> >

> >> > Also, has anyone verified this sysctl is filtering audit events? Even

> >> > with

> >> > the above, I have over a million events on a 4.14.3 kernel. Firefox

> >> > alone

> >> > is generating over 50,000 events per hour.

> >>

> >> I don't think you'd want to log errno -- AIUI, that's used regularly

> >> by a lot of seccomp policy.

> >

> > I'm not seeing any reporting errno. The ones reporting trap are coming in

> > over 50,000 per hour. I don't think the filter is working.

> >

> > [root@x2 ~]# cat /proc/sys/kernel/seccomp/actions_logged

> > kill_process kill_thread errno

> > [root@x2 ~]# date

> > Wed Dec 13 19:24:40 EST 2017

> > [root@x2 ~]# ausearch --start 19:24:40 -m seccomp --raw | aureport --event

> > --summary -i

> > Event Summary Report

> > ======================

> > total type

> > ======================

> > 170 SECCOMP

> >

> > In the time it took to type the command 170 seccomp events were recorded

> > from firefox.

> >

> > [root@x2 ~]# ausearch --start 19:24:40 -m seccomp --just-one -i

> > ----

> > node=x2 type=SECCOMP msg=audit(12/13/2017 19:24:56.454:199666) :

> > auid=sgrubb uid=sgrubb gid=sgrubb ses=3

> > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3394

> > comm=Web Content exe=/usr/lib64/firefox/firefox sig=SIG0 arch=x86_64

> > syscall=stat compat=0 ip=0x7f909c828635 code=trap

> > ^^ trap. With the sheer amount of events being recorded, I think it's

> > necessary to add a sysctl file to systems to suppress the logging.

> > Especially when you consider that systemd-journal also gratuitously grabs

> > audit logs and sends them to rsyslog.

>

> Looking at the kernel code, it looks like the actions_logged knob

> isn't really intended to filter/drop seccomp events,

 

That's unfortunate. I thought this was a way to suppress generation of events. We have a requirement that audit events be selective by the administrator. We need a knob to drop some events. I guess, the only knob right now is the exclude filter. That is probably too course.

 

> but rather force seccomp events to be loggged. Look at seccomp_log() to see

> what I mean; there is still a call to audit_seccomp() at the end.

 

Hmm. What do we do? I have more than a million seccomp events in 2 days. I'm getting 14 events a second for seccomp just using my system. It's flooding everything. I mean maybe the firefox and webkit people meant well using seccomp, but how does a normal user get control back of their logs?

 

Thanks,

-Steve

--nextPart3175413.1ar6XzAcRI-- --===============5574989825683947579== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============5574989825683947579==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: Limiting SECCOMP audit events Date: Thu, 14 Dec 2017 07:42:26 -0500 Message-ID: References: <58203247.sCqcla2mis@x2> <2483555.uM3AbUoQxj@x2> <17198747.0Wk1AduiP0@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx01.extmail.prod.ext.phx2.redhat.com [10.5.110.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C7BF66F978 for ; Thu, 14 Dec 2017 12:42:30 +0000 (UTC) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 584D06016A for ; Thu, 14 Dec 2017 12:42:29 +0000 (UTC) Received: by mail-lf0-f47.google.com with SMTP id f20so6502274lfe.3 for ; Thu, 14 Dec 2017 04:42:29 -0800 (PST) In-Reply-To: <17198747.0Wk1AduiP0@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: Linux Audit List-Id: linux-audit@redhat.com On Wed, Dec 13, 2017 at 10:30 PM, Steve Grubb wrote: > On Wednesday, December 13, 2017 8:43:38 PM EST Paul Moore wrote: >> On Wed, Dec 13, 2017 at 7:31 PM, Steve Grubb wrote: >> > On Wednesday, December 13, 2017 7:16:47 PM EST Kees Cook wrote: >> >> On Wed, Dec 13, 2017 at 3:58 PM, Steve Grubb wrote: ... >> Looking at the kernel code, it looks like the actions_logged knob >> isn't really intended to filter/drop seccomp events, > > That's unfortunate. I thought this was a way to suppress generation of > events. We have a requirement that audit events be selective by the > administrator. We need a knob to drop some events. I guess, the only knob > right now is the exclude filter. That is probably too course. > >> but rather force seccomp events to be loggged. Look at seccomp_log() to >> see what I mean; there is still a call to audit_seccomp() at the end. > > Hmm. What do we do? I imagine we could put together a rather coarse grained action filter, similar to what we have with "actions_logged" (maybe "actions_silent"?), and perhaps add some additional audit filters for seccomp for those who happen to have audit enabled. Both should be relatively easy, the "actions_silent" field especially so. -- paul moore www.paul-moore.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tyler Hicks Subject: Re: Limiting SECCOMP audit events Date: Thu, 14 Dec 2017 09:04:48 -0600 Message-ID: <36cd827f-201c-8f76-2883-ecd930cbb1f4@canonical.com> References: <58203247.sCqcla2mis@x2> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5913319243330256340==" Return-path: In-Reply-To: <58203247.sCqcla2mis@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb , Linux Audit List-Id: linux-audit@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============5913319243330256340== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UraUXeI7xGdDnSgue5b15hAcbTHjwHRAA" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UraUXeI7xGdDnSgue5b15hAcbTHjwHRAA Content-Type: multipart/mixed; boundary="70NBL8VU9P77ELFrtPC4tCJbxjKH3WCQk"; protected-headers="v1" From: Tyler Hicks To: Steve Grubb , Linux Audit Cc: Kees Cook , Paul Moore Message-ID: <36cd827f-201c-8f76-2883-ecd930cbb1f4@canonical.com> Subject: Re: Limiting SECCOMP audit events References: <58203247.sCqcla2mis@x2> In-Reply-To: <58203247.sCqcla2mis@x2> --70NBL8VU9P77ELFrtPC4tCJbxjKH3WCQk Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 12/13/2017 05:58 PM, Steve Grubb wrote: > Hello, >=20 > =A0 >=20 > Over the last month, the amount of seccomp events in audit logs is > sky-rocketing. I have over a million events in the last 2 days. Most of= > this is generated by firefox and qt webkit. >=20 > =A0 >=20 > I am wondering if the audit package should ship a file for >=20 > =A0 >=20 > /usr/lib/sysctl.d/60-auditd.conf >=20 > =A0 >=20 > wherein it has >=20 > =A0 >=20 > kernel.seccomp.actions_logged =3D kill_process kill_thread errno I agree with Kees here. IMO, you only want "kill_process kill_thread" which is the default. > Also, has anyone verified this sysctl is filtering audit events? Even > with the above, I have over a million events on a 4.14.3 kernel. Firefo= x > alone is generating over 50,000 events per hour. Yes. I tested it a lot as the changes were being upstreamed and again when I backported the changes to Ubuntu releases 17.10, 17.04, and 16.04 LTS. Those kernels have been released for a month and a half now and I haven't heard of any issues. I'll install a Fedora VM and see if I can determine what's happening. Tyler >=20 > =A0 >=20 > Thanks, >=20 > -Steve >=20 --70NBL8VU9P77ELFrtPC4tCJbxjKH3WCQk-- --UraUXeI7xGdDnSgue5b15hAcbTHjwHRAA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJaMpMQAAoJENaSAD2qAscKspgQAJHe2TiSh4cFdVwZWvLue/0H 53Xc1SBslgroqU/iHyRMBqfkTF4legSfXGRjHxQOVir58rOiOi8NLZN/NS0AhKgH WDyjZcEEOjISvQUYlSIZ0vdZS3J2YujPYa5yxiT3WwyhT5DCJrVfkBBNyP8MCLCh w2bWtHOd/uFkQ4mALmQRF6b4ugoWtEUByrPaCQErNpjz+I1220/UCLKzQwQ35GbB 7nSijRtk3Z5UYhVUhmUehhRGiZioR4RnUvnsXwbWLXxUc6UrptDtD6fvgYWBcgHW p/JjBUPVYinHuhw5/l+HGkryM5eKLBd3ytJtLS87GUeNWb7XKyRusrmxeByTp2q7 C7hrfU2OlnZKIkAHit6qSFh/Smoip/wdfQJAXH/cJit7rz2wrVQb9bEuu+ZJuapa zOR9aTSZ3tjOW3zMbXKuHmFv8+uLXpYjE+/pvZ/kummOSehXnTQfZPeEZPYOp9rI 4744pxmDKDbtuZOnaAR9K7Qs1sMAP9KW+cyLaaZxW2ypSV/So4QUgMj5EpT2u+sj T8dv8/ZY8fLTcH3eKDoXFJDMfVC5ujsiXSBlbmEMuQh4v+RQgyvmowCMJurKluL4 2gkIsxFDciK7E7ln1Y5Gfnpmj7i462GgQcwOUsO2IwfBjGFSz3lc8VwkBg5pV0jQ NvVJx4gvcK/eg6oOrt/I =xgqk -----END PGP SIGNATURE----- --UraUXeI7xGdDnSgue5b15hAcbTHjwHRAA-- --===============5913319243330256340== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============5913319243330256340==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Limiting SECCOMP audit events Date: Thu, 14 Dec 2017 10:19:41 -0500 Message-ID: <3499769.OM7YpPIT3e@x2> References: <58203247.sCqcla2mis@x2> <36cd827f-201c-8f76-2883-ecd930cbb1f4@canonical.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2128509352572596825==" Return-path: In-Reply-To: <36cd827f-201c-8f76-2883-ecd930cbb1f4@canonical.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Tyler Hicks Cc: Linux Audit List-Id: linux-audit@redhat.com This is a multi-part message in MIME format. --===============2128509352572596825== Content-Type: multipart/alternative; boundary="nextPart1901253.lJvmAx7LUS" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart1901253.lJvmAx7LUS Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Thursday, December 14, 2017 10:04:48 AM EST Tyler Hicks wrote: > On 12/13/2017 05:58 PM, Steve Grubb wrote: > > Over the last month, the amount of seccomp events in audit logs is > > sky-rocketing. I have over a million events in the last 2 days. Most of > > this is generated by firefox and qt webkit. > > > > I am wondering if the audit package should ship a file for > > > > /usr/lib/sysctl.d/60-auditd.conf > > > > wherein it has > > > > kernel.seccomp.actions_logged = kill_process kill_thread errno > > I agree with Kees here. IMO, you only want "kill_process kill_thread" > which is the default. The default appears to be all of the types of events without setting kernel.seccomp.actions_logged. > > Also, has anyone verified this sysctl is filtering audit events? Even > > with the above, I have over a million events on a 4.14.3 kernel. Firefox > > alone is generating over 50,000 events per hour. > > Yes. I tested it a lot as the changes were being upstreamed and again > when I backported the changes to Ubuntu releases 17.10, 17.04, and 16.04 > LTS. Those kernels have been released for a month and a half now and I > haven't heard of any issues. Apparently I misunderstood this as a filter for audit events to be blocked. > I'll install a Fedora VM and see if I can determine what's happening. I'm testing on F27 if that matters. It would appear to me that seccomp filtering is becoming more used and is now dominating the events going into the audit logs. # uptime 10:17:34 up 1:27, 1 user, load average: 0.23, 0.39, 0.53 [root@x2 ~]# ausearch --start today --raw | aureport --event --summary -i Event Summary Report ====================== total type ====================== 35561 SECCOMP 1041 SYSCALL 134 SERVICE_START 75 NETFILTER_CFG 46 SERVICE_STOP 46 CONFIG_CHANGE 24 AVC All of the seccomp events are trap types. -Steve --nextPart1901253.lJvmAx7LUS Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

On Thursday, December 14, 2017 10:04:48 AM EST Tyler Hicks wrote:

> On 12/13/2017 05:58 PM, Steve Grubb wrote:

> > Over the last month, the amount of seccomp events in audit logs is

> > sky-rocketing. I have over a million events in the last 2 days. Most of

> > this is generated by firefox and qt webkit.

> >

> > I am wondering if the audit package should ship a file for

> >

> > /usr/lib/sysctl.d/60-auditd.conf

> >

> > wherein it has

> >

> > kernel.seccomp.actions_logged = kill_process kill_thread errno

>

> I agree with Kees here. IMO, you only want "kill_process kill_thread"

> which is the default.

 

The default appears to be all of the types of events without setting kernel.seccomp.actions_logged.

 

> > Also, has anyone verified this sysctl is filtering audit events? Even

> > with the above, I have over a million events on a 4.14.3 kernel. Firefox

> > alone is generating over 50,000 events per hour.

>

> Yes. I tested it a lot as the changes were being upstreamed and again

> when I backported the changes to Ubuntu releases 17.10, 17.04, and 16.04

> LTS. Those kernels have been released for a month and a half now and I

> haven't heard of any issues.

 

Apparently I misunderstood this as a filter for audit events to be blocked.

 

> I'll install a Fedora VM and see if I can determine what's happening.

 

I'm testing on F27 if that matters. It would appear to me that seccomp filtering is becoming more used and is now dominating the events going into the audit logs.

 

# uptime

10:17:34 up 1:27, 1 user, load average: 0.23, 0.39, 0.53

 

[root@x2 ~]# ausearch --start today --raw | aureport --event --summary -i

 

Event Summary Report

======================

total type

======================

35561 SECCOMP

1041 SYSCALL

134 SERVICE_START

75 NETFILTER_CFG

46 SERVICE_STOP

46 CONFIG_CHANGE

24 AVC

 

All of the seccomp events are trap types.

 

-Steve

--nextPart1901253.lJvmAx7LUS-- --===============2128509352572596825== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============2128509352572596825==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Limiting SECCOMP audit events Date: Thu, 14 Dec 2017 10:29:38 -0500 Message-ID: <3367743.fjAuTK8mJQ@x2> References: <58203247.sCqcla2mis@x2> <17198747.0Wk1AduiP0@x2> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3108130692192665911==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Paul Moore Cc: Linux Audit List-Id: linux-audit@redhat.com This is a multi-part message in MIME format. --===============3108130692192665911== Content-Type: multipart/alternative; boundary="nextPart1960055.1CyWegJSjn" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart1960055.1CyWegJSjn Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Thursday, December 14, 2017 7:42:26 AM EST Paul Moore wrote: > >> Looking at the kernel code, it looks like the actions_logged knob > >> isn't really intended to filter/drop seccomp events, > > > > That's unfortunate. I thought this was a way to suppress generation of > > events. We have a requirement that audit events be selective by the > > administrator. We need a knob to drop some events. I guess, the only knob > > right now is the exclude filter. That is probably too course. > > > >> but rather force seccomp events to be loggged. Look at seccomp_log() to > >> see what I mean; there is still a call to audit_seccomp() at the end. > > > > Hmm. What do we do? > > I imagine we could put together a rather coarse grained action filter, > similar to what we have with "actions_logged" (maybe > "actions_silent"?), and perhaps add some additional audit filters for > seccomp for those who happen to have audit enabled. Both should be > relatively easy, the "actions_silent" field especially so. OK. That would be helpful. This is eating up my log space. The biggest offenders seem to be doing trap kind of events. I suppose if an errno was returned the program would respond by erroring out. But since its a trap, I suspect something looks around at data and then OK's it to proceed on which results in another trap. -Steve --nextPart1960055.1CyWegJSjn Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

On Thursday, December 14, 2017 7:42:26 AM EST Paul Moore wrote:

> >> Looking at the kernel code, it looks like the actions_logged knob

> >> isn't really intended to filter/drop seccomp events,

> >

> > That's unfortunate. I thought this was a way to suppress generation of

> > events. We have a requirement that audit events be selective by the

> > administrator. We need a knob to drop some events. I guess, the only knob

> > right now is the exclude filter. That is probably too course.

> >

> >> but rather force seccomp events to be loggged. Look at seccomp_log() to

> >> see what I mean; there is still a call to audit_seccomp() at the end.

> >

> > Hmm. What do we do?

>

> I imagine we could put together a rather coarse grained action filter,

> similar to what we have with "actions_logged" (maybe

> "actions_silent"?), and perhaps add some additional audit filters for

> seccomp for those who happen to have audit enabled. Both should be

> relatively easy, the "actions_silent" field especially so.

 

OK. That would be helpful. This is eating up my log space. The biggest offenders seem to be doing trap kind of events. I suppose if an errno was returned the program would respond by erroring out. But since its a trap, I suspect something looks around at data and then OK's it to proceed on which results in another trap.

 

-Steve

--nextPart1960055.1CyWegJSjn-- --===============3108130692192665911== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============3108130692192665911==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tyler Hicks Subject: Re: Limiting SECCOMP audit events Date: Thu, 14 Dec 2017 23:06:30 +0000 Message-ID: <20171214230629.GA451@sec> References: <58203247.sCqcla2mis@x2> <36cd827f-201c-8f76-2883-ecd930cbb1f4@canonical.com> <3499769.OM7YpPIT3e@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <3499769.OM7YpPIT3e@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: Linux Audit List-Id: linux-audit@redhat.com On 12/14/2017 09:19 AM, Steve Grubb wrote: > On Thursday, December 14, 2017 10:04:48 AM EST Tyler Hicks wrote: > = >> On 12/13/2017 05:58 PM, Steve Grubb wrote: > = >> > Over the last month, the amount of seccomp events in audit logs is > = >> > sky-rocketing. I have over a million events in the last 2 days. Most of > = >> > this is generated by firefox and qt webkit. > = >> > > = >> > I am wondering if the audit package should ship a file for > = >> > > = >> > /usr/lib/sysctl.d/60-auditd.conf > = >> > > = >> > wherein it has > = >> > > = >> > kernel.seccomp.actions_logged =3D kill_process kill_thread errno > = >> > = >> I agree with Kees here. IMO, you only want "kill_process kill_thread" > = >> which is the default. > = > =A0 > = > The default appears to be all of the types of events without setting > kernel.seccomp.actions_logged. Ah, right. I didn't correctly remember the final implementation details. The default sysctl setting is to allow all actions except for RET_ALLOW to be logged. I think the easiest description of the logic is in the commit message of 59f5cf44a38284eb9e76270c786fb6cc62ef8ac4: if action =3D=3D RET_ALLOW: do not log else if action =3D=3D RET_KILL && RET_KILL in actions_logged: log else if action =3D=3D 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 I think I originally misunderstood your first email in this thread. I thought you were saying that you were experiencing more seccomp audit events in 4.14 versus 4.13 and that you felt a regression had been introduced. After rereading, I think you're asking why you're getting seccomp RET_TRAP actions logged even though "trap" isn't in the actions_logged sysctl. = The reason is because I didn't get clear direction from the audit folks about to do when audit is enabled and the process is being audited and, therefore, I didn't feel comfortable rocking the boat. In that situation, the decision to log is the same as it was in earlier kernels. Specifically, you're hitting the last "else if" conditional in the pseudocode above. If you're happy with having the actions_logged sysctl control whether or not to log seccomp actions taken for processes that are being audited, then I think the following (untested) patch should do exactly what you want. I imagine that you'd also want seccomp to emit audit events whenever the value of the actions_logged sysctl is changed, which should be pretty easy to do. I hope this helps! Tyler diff --git a/include/linux/audit.h b/include/linux/audit.h index af410d9..095b5dd 100644 --- a/include/linux/audit.h +++ b/include/linux/audit.h @@ -304,12 +304,6 @@ static inline void audit_inode_child(struct inode *par= ent, } void audit_core_dumps(long signr); = -static inline void audit_seccomp(unsigned long syscall, long signr, int co= de) -{ - if (audit_enabled && unlikely(!audit_dummy_context())) - __audit_seccomp(syscall, signr, code); -} - static inline void audit_ptrace(struct task_struct *t) { if (unlikely(!audit_dummy_context())) @@ -502,8 +496,6 @@ static inline void audit_core_dumps(long signr) { } static inline void __audit_seccomp(unsigned long syscall, long signr, int = code) { } -static inline void audit_seccomp(unsigned long syscall, long signr, int co= de) -{ } static inline int auditsc_get_stamp(struct audit_context *ctx, struct timespec64 *t, unsigned int *serial) { diff --git a/kernel/seccomp.c b/kernel/seccomp.c index 5f0dfb2ab..914a707 100644 --- a/kernel/seccomp.c +++ b/kernel/seccomp.c @@ -590,12 +590,6 @@ static inline void seccomp_log(unsigned long syscall, = long signr, u32 action, */ if (log) return __audit_seccomp(syscall, signr, action); - - /* - * Let the audit subsystem decide if the action should be audited based - * on whether the current task itself is being audited. - */ - return audit_seccomp(syscall, signr, action); } = /* From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: Limiting SECCOMP audit events Date: Thu, 14 Dec 2017 15:16:18 -0800 Message-ID: References: <58203247.sCqcla2mis@x2> <36cd827f-201c-8f76-2883-ecd930cbb1f4@canonical.com> <3499769.OM7YpPIT3e@x2> <20171214230629.GA451@sec> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx08.extmail.prod.ext.phx2.redhat.com [10.5.110.32]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 25F255C549 for ; Thu, 14 Dec 2017 23:16:22 +0000 (UTC) Received: from mail-vk0-f66.google.com (mail-vk0-f66.google.com [209.85.213.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DA3BAC033476 for ; Thu, 14 Dec 2017 23:16:20 +0000 (UTC) Received: by mail-vk0-f66.google.com with SMTP id x140so4581546vke.4 for ; Thu, 14 Dec 2017 15:16:20 -0800 (PST) In-Reply-To: <20171214230629.GA451@sec> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Tyler Hicks Cc: Linux Audit List-Id: linux-audit@redhat.com On Thu, Dec 14, 2017 at 3:06 PM, Tyler Hicks wrote: > The reason is because I didn't get clear direction from the audit > folks about to do when audit is enabled and the process is being audited > and, therefore, I didn't feel comfortable rocking the boat. In that > situation, the decision to log is the same as it was in earlier kernels. > Specifically, you're hitting the last "else if" conditional in the > pseudocode above. Yeah, same for me: it's been entirely unclear what the desired combination of audit vs seccomp should be. It seems like it should be reporting everything when auditing a specific process, and then ... something else? ... in the global context. > If you're happy with having the actions_logged sysctl control whether or > not to log seccomp actions taken for processes that are being audited, > then I think the following (untested) patch should do exactly what you > want. I imagine that you'd also want seccomp to emit audit events > whenever the value of the actions_logged sysctl is changed, which should > be pretty easy to do. > > I hope this helps! > > Tyler > > diff --git a/include/linux/audit.h b/include/linux/audit.h > index af410d9..095b5dd 100644 > --- a/include/linux/audit.h > +++ b/include/linux/audit.h > @@ -304,12 +304,6 @@ static inline void audit_inode_child(struct inode *parent, > } > void audit_core_dumps(long signr); > > -static inline void audit_seccomp(unsigned long syscall, long signr, int code) > -{ > - if (audit_enabled && unlikely(!audit_dummy_context())) > - __audit_seccomp(syscall, signr, code); > -} > - > static inline void audit_ptrace(struct task_struct *t) > { > if (unlikely(!audit_dummy_context())) > @@ -502,8 +496,6 @@ static inline void audit_core_dumps(long signr) > { } > static inline void __audit_seccomp(unsigned long syscall, long signr, int code) > { } > -static inline void audit_seccomp(unsigned long syscall, long signr, int code) > -{ } > static inline int auditsc_get_stamp(struct audit_context *ctx, > struct timespec64 *t, unsigned int *serial) > { > diff --git a/kernel/seccomp.c b/kernel/seccomp.c > index 5f0dfb2ab..914a707 100644 > --- a/kernel/seccomp.c > +++ b/kernel/seccomp.c > @@ -590,12 +590,6 @@ static inline void seccomp_log(unsigned long syscall, long signr, u32 action, > */ > if (log) > return __audit_seccomp(syscall, signr, action); > - > - /* > - * Let the audit subsystem decide if the action should be audited based > - * on whether the current task itself is being audited. > - */ > - return audit_seccomp(syscall, signr, action); > } > > /* If audit folks are happy with this, I am too. :) -Kees -- Kees Cook Pixel Security From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: Limiting SECCOMP audit events Date: Fri, 15 Dec 2017 09:08:05 -0500 Message-ID: <1605a80e588.280e.85c95baa4474aabc7814e68940a78392@paul-moore.com> References: <58203247.sCqcla2mis@x2> <36cd827f-201c-8f76-2883-ecd930cbb1f4@canonical.com> <3499769.OM7YpPIT3e@x2> <20171214230629.GA451@sec> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mx1.redhat.com (ext-mx02.extmail.prod.ext.phx2.redhat.com [10.5.110.26]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D97517C3E1 for ; Fri, 15 Dec 2017 14:08:16 +0000 (UTC) Received: from mail-it0-f65.google.com (mail-it0-f65.google.com [209.85.214.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1DE89883B9 for ; Fri, 15 Dec 2017 14:08:10 +0000 (UTC) Received: by mail-it0-f65.google.com with SMTP id f190so19175025ita.5 for ; Fri, 15 Dec 2017 06:08:10 -0800 (PST) In-Reply-To: <20171214230629.GA451@sec> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Tyler Hicks , Steve Grubb Cc: Linux Audit List-Id: linux-audit@redhat.com T24gRGVjZW1iZXIgMTQsIDIwMTcgNjowNjo0OSBQTSBUeWxlciBIaWNrcyA8dHloaWNrc0BjYW5v bmljYWwuY29tPiB3cm90ZToKCj4gT24gMTIvMTQvMjAxNyAwOToxOSBBTSwgU3RldmUgR3J1YmIg d3JvdGU6Cj4+IE9uIFRodXJzZGF5LCBEZWNlbWJlciAxNCwgMjAxNyAxMDowNDo0OCBBTSBFU1Qg VHlsZXIgSGlja3Mgd3JvdGU6Cj4+Cj4+PiBPbiAxMi8xMy8yMDE3IDA1OjU4IFBNLCBTdGV2ZSBH cnViYiB3cm90ZToKPj4KPj4+ID4gT3ZlciB0aGUgbGFzdCBtb250aCwgdGhlIGFtb3VudCBvZiBz ZWNjb21wIGV2ZW50cyBpbiBhdWRpdCBsb2dzIGlzCj4+Cj4+PiA+IHNreS1yb2NrZXRpbmcuIEkg aGF2ZSBvdmVyIGEgbWlsbGlvbiBldmVudHMgaW4gdGhlIGxhc3QgMiBkYXlzLiBNb3N0IG9mCj4+ Cj4+PiA+IHRoaXMgaXMgZ2VuZXJhdGVkIGJ5IGZpcmVmb3ggYW5kIHF0IHdlYmtpdC4KPj4KPj4+ ID4KPj4KPj4+ID4gSSBhbSB3b25kZXJpbmcgaWYgdGhlIGF1ZGl0IHBhY2thZ2Ugc2hvdWxkIHNo aXAgYSBmaWxlIGZvcgo+Pgo+Pj4gPgo+Pgo+Pj4gPiAvdXNyL2xpYi9zeXNjdGwuZC82MC1hdWRp dGQuY29uZgo+Pgo+Pj4gPgo+Pgo+Pj4gPiB3aGVyZWluIGl0IGhhcwo+Pgo+Pj4gPgo+Pgo+Pj4g PiBrZXJuZWwuc2VjY29tcC5hY3Rpb25zX2xvZ2dlZCA9IGtpbGxfcHJvY2VzcyBraWxsX3RocmVh ZCBlcnJubwo+Pgo+Pj4KPj4KPj4+IEkgYWdyZWUgd2l0aCBLZWVzIGhlcmUuIElNTywgeW91IG9u bHkgd2FudCAia2lsbF9wcm9jZXNzIGtpbGxfdGhyZWFkIgo+Pgo+Pj4gd2hpY2ggaXMgdGhlIGRl ZmF1bHQuCj4+Cj4+IMKgCj4+Cj4+IFRoZSBkZWZhdWx0IGFwcGVhcnMgdG8gYmUgYWxsIG9mIHRo ZSB0eXBlcyBvZiBldmVudHMgd2l0aG91dCBzZXR0aW5nCj4+IGtlcm5lbC5zZWNjb21wLmFjdGlv bnNfbG9nZ2VkLgo+Cj4gQWgsIHJpZ2h0LiBJIGRpZG4ndCBjb3JyZWN0bHkgcmVtZW1iZXIgdGhl IGZpbmFsIGltcGxlbWVudGF0aW9uIGRldGFpbHMuCj4gVGhlIGRlZmF1bHQgc3lzY3RsIHNldHRp bmcgaXMgdG8gYWxsb3cgYWxsIGFjdGlvbnMgZXhjZXB0IGZvciBSRVRfQUxMT1cKPiB0byBiZSBs b2dnZWQuCj4KPiBJIHRoaW5rIHRoZSBlYXNpZXN0IGRlc2NyaXB0aW9uIG9mIHRoZSBsb2dpYyBp cyBpbiB0aGUgY29tbWl0IG1lc3NhZ2Ugb2YKPiA1OWY1Y2Y0NGEzODI4NGViOWU3NjI3MGM3ODZm YjZjYzYyZWY4YWM0Ogo+Cj4gICAgIGlmIGFjdGlvbiA9PSBSRVRfQUxMT1c6Cj4gICAgICAgZG8g bm90IGxvZwo+ICAgICBlbHNlIGlmIGFjdGlvbiA9PSBSRVRfS0lMTCAmJiBSRVRfS0lMTCBpbiBh Y3Rpb25zX2xvZ2dlZDoKPiAgICAgICBsb2cKPiAgICAgZWxzZSBpZiBhY3Rpb24gPT0gUkVUX0xP RyAmJiBSRVRfTE9HIGluIGFjdGlvbnNfbG9nZ2VkOgo+ICAgICAgIGxvZwo+ICAgICBlbHNlIGlm IGZpbHRlci1yZXF1ZXN0cy1sb2dnaW5nICYmIGFjdGlvbiBpbiBhY3Rpb25zX2xvZ2dlZDoKPiAg ICAgICBsb2cKPiAgICAgZWxzZSBpZiBhdWRpdF9lbmFibGVkICYmIHByb2Nlc3MtaXMtYmVpbmct YXVkaXRlZDoKPiAgICAgICBsb2cKPiAgICAgZWxzZToKPiAgICAgICBkbyBub3QgbG9nCj4KPiBJ IHRoaW5rIEkgb3JpZ2luYWxseSBtaXN1bmRlcnN0b29kIHlvdXIgZmlyc3QgZW1haWwgaW4gdGhp cyB0aHJlYWQuIEkKPiB0aG91Z2h0IHlvdSB3ZXJlIHNheWluZyB0aGF0IHlvdSB3ZXJlIGV4cGVy aWVuY2luZyBtb3JlIHNlY2NvbXAgYXVkaXQKPiBldmVudHMgaW4gNC4xNCB2ZXJzdXMgNC4xMyBh bmQgdGhhdCB5b3UgZmVsdCBhIHJlZ3Jlc3Npb24gaGFkIGJlZW4KPiBpbnRyb2R1Y2VkLiBBZnRl ciByZXJlYWRpbmcsIEkgdGhpbmsgeW91J3JlIGFza2luZyB3aHkgeW91J3JlIGdldHRpbmcKPiBz ZWNjb21wIFJFVF9UUkFQIGFjdGlvbnMgbG9nZ2VkIGV2ZW4gdGhvdWdoICJ0cmFwIiBpc24ndCBp biB0aGUKPiBhY3Rpb25zX2xvZ2dlZCBzeXNjdGwuCj4KPiBUaGUgcmVhc29uIGlzIGJlY2F1c2Ug SSBkaWRuJ3QgZ2V0IGNsZWFyIGRpcmVjdGlvbiBmcm9tIHRoZSBhdWRpdAo+IGZvbGtzIGFib3V0 IHRvIGRvIHdoZW4gYXVkaXQgaXMgZW5hYmxlZCBhbmQgdGhlIHByb2Nlc3MgaXMgYmVpbmcgYXVk aXRlZAo+IGFuZCwgdGhlcmVmb3JlLCBJIGRpZG4ndCBmZWVsIGNvbWZvcnRhYmxlIHJvY2tpbmcg dGhlIGJvYXQuIEluIHRoYXQKPiBzaXR1YXRpb24sIHRoZSBkZWNpc2lvbiB0byBsb2cgaXMgdGhl IHNhbWUgYXMgaXQgd2FzIGluIGVhcmxpZXIga2VybmVscy4KPiBTcGVjaWZpY2FsbHksIHlvdSdy ZSBoaXR0aW5nIHRoZSBsYXN0ICJlbHNlIGlmIiBjb25kaXRpb25hbCBpbiB0aGUKPiBwc2V1ZG9j b2RlIGFib3ZlLgo+Cj4gSWYgeW91J3JlIGhhcHB5IHdpdGggaGF2aW5nIHRoZSBhY3Rpb25zX2xv Z2dlZCBzeXNjdGwgY29udHJvbCB3aGV0aGVyIG9yCj4gbm90IHRvIGxvZyBzZWNjb21wIGFjdGlv bnMgdGFrZW4gZm9yIHByb2Nlc3NlcyB0aGF0IGFyZSBiZWluZyBhdWRpdGVkLAo+IHRoZW4gSSB0 aGluayB0aGUgZm9sbG93aW5nICh1bnRlc3RlZCkgcGF0Y2ggc2hvdWxkIGRvIGV4YWN0bHkgd2hh dCB5b3UKPiB3YW50LiBJIGltYWdpbmUgdGhhdCB5b3UnZCBhbHNvIHdhbnQgc2VjY29tcCB0byBl bWl0IGF1ZGl0IGV2ZW50cwo+IHdoZW5ldmVyIHRoZSB2YWx1ZSBvZiB0aGUgYWN0aW9uc19sb2dn ZWQgc3lzY3RsIGlzIGNoYW5nZWQsIHdoaWNoIHNob3VsZAo+IGJlIHByZXR0eSBlYXN5IHRvIGRv Lgo+Cj4gSSBob3BlIHRoaXMgaGVscHMhCj4KPiBUeWxlcgo+Cj4gZGlmZiAtLWdpdCBhL2luY2x1 ZGUvbGludXgvYXVkaXQuaCBiL2luY2x1ZGUvbGludXgvYXVkaXQuaAo+IGluZGV4IGFmNDEwZDku LjA5NWI1ZGQgMTAwNjQ0Cj4gLS0tIGEvaW5jbHVkZS9saW51eC9hdWRpdC5oCj4gKysrIGIvaW5j bHVkZS9saW51eC9hdWRpdC5oCj4gQEAgLTMwNCwxMiArMzA0LDYgQEAgc3RhdGljIGlubGluZSB2 b2lkIGF1ZGl0X2lub2RlX2NoaWxkKHN0cnVjdCBpbm9kZSAqcGFyZW50LAo+ICB9Cj4gIHZvaWQg YXVkaXRfY29yZV9kdW1wcyhsb25nIHNpZ25yKTsKPgo+IC1zdGF0aWMgaW5saW5lIHZvaWQgYXVk aXRfc2VjY29tcCh1bnNpZ25lZCBsb25nIHN5c2NhbGwsIGxvbmcgc2lnbnIsIGludCBjb2RlKQo+ IC17Cj4gLQlpZiAoYXVkaXRfZW5hYmxlZCAmJiB1bmxpa2VseSghYXVkaXRfZHVtbXlfY29udGV4 dCgpKSkKPiAtCQlfX2F1ZGl0X3NlY2NvbXAoc3lzY2FsbCwgc2lnbnIsIGNvZGUpOwo+IC19Cj4g LQoKTG9va3MgZ29vZCB0byBtZSBidXQgdHdvIHRoaW5nczoKCiogQ2hhbmdlIHRoZSBuYW1lIG9m IF9fYXVkaXRfc2VjY29tcCgpIHRvIGF1ZGl0X3NlY2NvbXAoKSBzaW5jZSB3ZSBkb24ndApoYXZl IHR3byBmdW5jdGlvbnMgYW55bW9yZS4KCiogQXJlIHdlIHN1cmUgYWJvdXQgcmVtb3ZpbmcgdGhl IGF1ZGl0X2VuYWJsZWQgY2hlY2s/IFBlb3BsZSBnb3QgcHJldHR5CnVwc2V0IHdoZW4gaXQgd2Fz bid0IHRoZXJlIGluIHRoZSBwYXN0LgoKPiAgc3RhdGljIGlubGluZSB2b2lkIGF1ZGl0X3B0cmFj ZShzdHJ1Y3QgdGFza19zdHJ1Y3QgKnQpCj4gIHsKPiAgCWlmICh1bmxpa2VseSghYXVkaXRfZHVt bXlfY29udGV4dCgpKSkKPiBAQCAtNTAyLDggKzQ5Niw2IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBh dWRpdF9jb3JlX2R1bXBzKGxvbmcgc2lnbnIpCj4gIHsgfQo+ICBzdGF0aWMgaW5saW5lIHZvaWQg X19hdWRpdF9zZWNjb21wKHVuc2lnbmVkIGxvbmcgc3lzY2FsbCwgbG9uZyBzaWduciwgaW50IGNv ZGUpCj4gIHsgfQo+IC1zdGF0aWMgaW5saW5lIHZvaWQgYXVkaXRfc2VjY29tcCh1bnNpZ25lZCBs b25nIHN5c2NhbGwsIGxvbmcgc2lnbnIsIGludCBjb2RlKQo+IC17IH0KPiAgc3RhdGljIGlubGlu ZSBpbnQgYXVkaXRzY19nZXRfc3RhbXAoc3RydWN0IGF1ZGl0X2NvbnRleHQgKmN0eCwKPiAgCQkJ ICAgICAgc3RydWN0IHRpbWVzcGVjNjQgKnQsIHVuc2lnbmVkIGludCAqc2VyaWFsKQo+ICB7Cj4g ZGlmZiAtLWdpdCBhL2tlcm5lbC9zZWNjb21wLmMgYi9rZXJuZWwvc2VjY29tcC5jCj4gaW5kZXgg NWYwZGZiMmFiLi45MTRhNzA3IDEwMDY0NAo+IC0tLSBhL2tlcm5lbC9zZWNjb21wLmMKPiArKysg Yi9rZXJuZWwvc2VjY29tcC5jCj4gQEAgLTU5MCwxMiArNTkwLDYgQEAgc3RhdGljIGlubGluZSB2 b2lkIHNlY2NvbXBfbG9nKHVuc2lnbmVkIGxvbmcgc3lzY2FsbCwKPiBsb25nIHNpZ25yLCB1MzIg YWN0aW9uLAo+ICAJICovCj4gIAlpZiAobG9nKQo+ICAJCXJldHVybiBfX2F1ZGl0X3NlY2NvbXAo c3lzY2FsbCwgc2lnbnIsIGFjdGlvbik7Cj4gLQo+IC0JLyoKPiAtCSAqIExldCB0aGUgYXVkaXQg c3Vic3lzdGVtIGRlY2lkZSBpZiB0aGUgYWN0aW9uIHNob3VsZCBiZSBhdWRpdGVkIGJhc2VkCj4g LQkgKiBvbiB3aGV0aGVyIHRoZSBjdXJyZW50IHRhc2sgaXRzZWxmIGlzIGJlaW5nIGF1ZGl0ZWQu Cj4gLQkgKi8KPiAtCXJldHVybiBhdWRpdF9zZWNjb21wKHN5c2NhbGwsIHNpZ25yLCBhY3Rpb24p Owo+ICB9Cj4KPiAgLyoKPgo+IC0tCj4gTGludXgtYXVkaXQgbWFpbGluZyBsaXN0Cj4gTGludXgt YXVkaXRAcmVkaGF0LmNvbQo+IGh0dHBzOi8vd3d3LnJlZGhhdC5jb20vbWFpbG1hbi9saXN0aW5m by9saW51eC1hdWRpdAoKCi0tCkxpbnV4LWF1ZGl0IG1haWxpbmcgbGlzdApMaW51eC1hdWRpdEBy ZWRoYXQuY29tCmh0dHBzOi8vd3d3LnJlZGhhdC5jb20vbWFpbG1hbi9saXN0aW5mby9saW51eC1h dWRpdA== From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tyler Hicks Subject: Re: Limiting SECCOMP audit events Date: Fri, 15 Dec 2017 15:47:14 +0000 Message-ID: <20171215154713.GA16170@sec> References: <58203247.sCqcla2mis@x2> <36cd827f-201c-8f76-2883-ecd930cbb1f4@canonical.com> <3499769.OM7YpPIT3e@x2> <20171214230629.GA451@sec> <1605a80e588.280e.85c95baa4474aabc7814e68940a78392@paul-moore.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8718256544430125752==" Return-path: In-Reply-To: <1605a80e588.280e.85c95baa4474aabc7814e68940a78392@paul-moore.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Paul Moore , Steve Grubb Cc: Linux Audit List-Id: linux-audit@redhat.com --===============8718256544430125752== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12/15/2017 08:08 AM, Paul Moore wrote: > On December 14, 2017 6:06:49 PM Tyler Hicks wrote: >=20 >> On 12/14/2017 09:19 AM, Steve Grubb wrote: >>> On Thursday, December 14, 2017 10:04:48 AM EST Tyler Hicks wrote: >>> >>>> On 12/13/2017 05:58 PM, Steve Grubb wrote: >>> >>>>> Over the last month, the amount of seccomp events in audit logs is >>> >>>>> sky-rocketing. I have over a million events in the last 2 days. Most = of >>> >>>>> this is generated by firefox and qt webkit. >>> >>>>> >>> >>>>> I am wondering if the audit package should ship a file for >>> >>>>> >>> >>>>> /usr/lib/sysctl.d/60-auditd.conf >>> >>>>> >>> >>>>> wherein it has >>> >>>>> >>> >>>>> kernel.seccomp.actions_logged =3D kill_process kill_thread errno >>> >>>> >>> >>>> I agree with Kees here. IMO, you only want "kill_process kill_thread" >>> >>>> which is the default. >>> >>> =A0 >>> >>> The default appears to be all of the types of events without setting >>> kernel.seccomp.actions_logged. >> >> Ah, right. I didn't correctly remember the final implementation details. >> The default sysctl setting is to allow all actions except for RET_ALLOW >> to be logged. >> >> I think the easiest description of the logic is in the commit message of >> 59f5cf44a38284eb9e76270c786fb6cc62ef8ac4: >> >> if action =3D=3D RET_ALLOW: >> do not log >> else if action =3D=3D RET_KILL && RET_KILL in actions_logged: >> log >> else if action =3D=3D 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 >> >> I think I originally misunderstood your first email in this thread. I >> thought you were saying that you were experiencing more seccomp audit >> events in 4.14 versus 4.13 and that you felt a regression had been >> introduced. After rereading, I think you're asking why you're getting >> seccomp RET_TRAP actions logged even though "trap" isn't in the >> actions_logged sysctl. >> >> The reason is because I didn't get clear direction from the audit >> folks about to do when audit is enabled and the process is being audited >> and, therefore, I didn't feel comfortable rocking the boat. In that >> situation, the decision to log is the same as it was in earlier kernels. >> Specifically, you're hitting the last "else if" conditional in the >> pseudocode above. >> >> If you're happy with having the actions_logged sysctl control whether or >> not to log seccomp actions taken for processes that are being audited, >> then I think the following (untested) patch should do exactly what you >> want. I imagine that you'd also want seccomp to emit audit events >> whenever the value of the actions_logged sysctl is changed, which should >> be pretty easy to do. >> >> I hope this helps! >> >> Tyler >> >> diff --git a/include/linux/audit.h b/include/linux/audit.h >> index af410d9..095b5dd 100644 >> --- a/include/linux/audit.h >> +++ b/include/linux/audit.h >> @@ -304,12 +304,6 @@ static inline void audit_inode_child(struct inode *= parent, >> } >> void audit_core_dumps(long signr); >> >> -static inline void audit_seccomp(unsigned long syscall, long signr, int= code) >> -{ >> - if (audit_enabled && unlikely(!audit_dummy_context())) >> - __audit_seccomp(syscall, signr, code); >> -} >> - >=20 > Looks good to me but two things: >=20 > * Change the name of __audit_seccomp() to audit_seccomp() since we don't > have two functions anymore. >=20 > * Are we sure about removing the audit_enabled check? People got pretty > upset when it wasn't there in the past. Do you have any references to the complaints so that we can understand them better? I remember being surprised by commit 96368701 adding the audit_enabled check (my fault for not watching the list closer) and having to revert it in Ubuntu with a distro patch. After sleeping on it for a night, I'm now unsure if the patch I sent in this thread is what you guys really want. I'll go back to talking in pseudocode. This is what we have in 4.14: if action =3D=3D RET_ALLOW: do not log else if action =3D=3D RET_KILL && RET_KILL in actions_logged: log else if action =3D=3D 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 This is what the patch in this thread does: --- a/seccomp-log.pseudo +++ b/seccomp-log.pseudo @@ -6,7 +6,5 @@ log else if filter-requests-logging && action in actions_logged: log - else if audit_enabled && process-is-being-audited: - log else: do not log Instead of that change, now I'm wondering if this is what you really want: --- a/seccomp-log.pseudo +++ b/seccomp-log.pseudo @@ -6,7 +6,8 @@ log else if filter-requests-logging && action in actions_logged: log - else if audit_enabled && process-is-being-audited: + else if audit_enabled && process-is-being-audited && + action in actions_logged: log else: do not log After refactoring the 'action in actions_logged' check, it would leave us with this: if action =3D=3D RET_ALLOW: do not log else if action not in actions_logged: do not log else if action =3D=3D RET_KILL: log else if action =3D=3D RET_LOG: log else if filter-requests-logging: log else if audit_enabled && process-is-being-audited: log else: do not log Tyler >=20 >> static inline void audit_ptrace(struct task_struct *t) >> { >> if (unlikely(!audit_dummy_context())) >> @@ -502,8 +496,6 @@ static inline void audit_core_dumps(long signr) >> { } >> static inline void __audit_seccomp(unsigned long syscall, long signr, i= nt code) >> { } >> -static inline void audit_seccomp(unsigned long syscall, long signr, int= code) >> -{ } >> static inline int auditsc_get_stamp(struct audit_context *ctx, >> struct timespec64 *t, unsigned int *serial) >> { >> diff --git a/kernel/seccomp.c b/kernel/seccomp.c >> index 5f0dfb2ab..914a707 100644 >> --- a/kernel/seccomp.c >> +++ b/kernel/seccomp.c >> @@ -590,12 +590,6 @@ static inline void seccomp_log(unsigned long syscal= l, >> long signr, u32 action, >> */ >> if (log) >> return __audit_seccomp(syscall, signr, action); >> - >> - /* >> - * Let the audit subsystem decide if the action should be audited based >> - * on whether the current task itself is being audited. >> - */ >> - return audit_seccomp(syscall, signr, action); >> } >> >> /* >> >> -- >> Linux-audit mailing list >> Linux-audit@redhat.com >> https://www.redhat.com/mailman/listinfo/linux-audit >=20 >=20 --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJaM+6BAAoJENaSAD2qAscKWm8QAMHHnbcuFMV9D8dZejpjwrmT E54ANOR//JuNmmv/QjHMeasH1+CLOnI611WcxLDl3F5QqUr3IjYUuY0nmNWR/miT Qao4znteRuuX6xQF085EWCScI2aCco1BxrW6DW2t477/5OQADJkyZ5EmWDuvUeBL QJ3raiMf04qbgTX+hghE6xjPJc7/3ZrDJjRhMHBul5YobauoLcgwKTyZWdMyJKW1 UK+IvDlPBe7UvPTSh7KaLPsiV5FB1qtQh4fdCs0UPCdf0BRxfKsUQuY7r8f4swbF klIvfHHRZsdjA/YEp5ZYg+Lju+ddajyRhJuPZXE2YKCnzAhQO4Fxvybol1xxU6hk MC0MW3UrFp3+hj+Wvcc3/PfuvZPVd/QMsRCc4kBdAYV6VA5hJ3IyzUHx1HyPLUat rd7atZldIhEZGT0o5f/i9/uxyI12ZCDHCaiUhzApZitCJwJv5KVHJXwlyyWR81Ke v/EVy6Bo0V/pjY/OgDFKdpCLoNd4CPebyvAjzcbr27o+NJeOYQZFhUJXpVxKcB6L cHmWz46sQ+rWaSWeoztagf20UvtSUhUZE+Ae0FgtMBsEKBlxK/xXm2rAVBU6sTI6 2ZML/Fs2j/XIGhXLastG6BdbxhKIgTTDVyMOn4JlRwyGIpcMk5sExrJh0ofWzinN 0AvS8jagjPW00eMDA8UD =KwxS -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- --===============8718256544430125752== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============8718256544430125752==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Limiting SECCOMP audit events Date: Fri, 15 Dec 2017 11:02:19 -0500 Message-ID: <3854763.JcSRc28zaO@x2> References: <58203247.sCqcla2mis@x2> <3499769.OM7YpPIT3e@x2> <20171214230629.GA451@sec> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20171214230629.GA451@sec> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Tyler Hicks Cc: Linux Audit List-Id: linux-audit@redhat.com On Thursday, December 14, 2017 6:06:30 PM EST Tyler Hicks wrote: > On 12/14/2017 09:19 AM, Steve Grubb wrote: > > On Thursday, December 14, 2017 10:04:48 AM EST Tyler Hicks wrote: > >> On 12/13/2017 05:58 PM, Steve Grubb wrote: > >> > Over the last month, the amount of seccomp events in audit logs is > >> > > >> > sky-rocketing. I have over a million events in the last 2 days. Most of > >> > > >> > this is generated by firefox and qt webkit. > >> > > >> > > >> > > >> > I am wondering if the audit package should ship a file for > >> > > >> > > >> > > >> > /usr/lib/sysctl.d/60-auditd.conf > >> > > >> > > >> > > >> > wherein it has > >> > > >> > > >> > > >> > kernel.seccomp.actions_logged = kill_process kill_thread errno > >> > >> I agree with Kees here. IMO, you only want "kill_process kill_thread" > >> > >> which is the default. > > > > > > > > The default appears to be all of the types of events without setting > > kernel.seccomp.actions_logged. > > Ah, right. I didn't correctly remember the final implementation details. > The default sysctl setting is to allow all actions except for RET_ALLOW > to be logged. > > I think the easiest description of the logic is in the commit message of > 59f5cf44a38284eb9e76270c786fb6cc62ef8ac4: > > 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 > > I think I originally misunderstood your first email in this thread. I > thought you were saying that you were experiencing more seccomp audit > events in 4.14 versus 4.13 and that you felt a regression had been > introduced. After rereading, I think you're asking why you're getting > seccomp RET_TRAP actions logged even though "trap" isn't in the > actions_logged sysctl. Yes, exactly. I have been experiencing large amounts of SECCOMP events starting with qt webkit in kde and thought 4.14 would finally let me tame those events. I have opened a couple bz asking developers if they really meant to go live with a policy that is experiencing so many denials. But the consensus is this is intended. (But I think they also have not actually tried to use their audit logs.) > The reason is because I didn't get clear direction from the audit > folks about to do when audit is enabled and the process is being audited > and, therefore, I didn't feel comfortable rocking the boat. In that > situation, the decision to log is the same as it was in earlier kernels. > Specifically, you're hitting the last "else if" conditional in the > pseudocode above. And here I thought you were also seeing large numbers of seccomp events and were making a way to control what gets logged. In any event, I think we better understand each other now. :-) > If you're happy with having the actions_logged sysctl control whether or > not to log seccomp actions taken for processes that are being audited, > then I think the following (untested) patch should do exactly what you > want. OK. Great. With developers starting to use the trap return value, audit logs are getting swamped by benign events. We truly need a knob to eliminate the noise from the signal. > I imagine that you'd also want seccomp to emit audit events whenever the > value of the actions_logged sysctl is changed, which should be pretty easy > to do. Sure. If you want to add it, then it should be roughly like this: struct tty_struct *tty; const struct cred *cred; struct audit_buffer *ab; char comm[sizeof(current->comm)]; ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE); if (unlikely(!ab)) return; cred = current_cred(); tty = audit_get_tty(current); audit_log_format(ab, "pid=%d uid=%u auid=%u tty=%s ses=%u", task_tgid_nr(current), from_kuid(&init_user_ns, cred->uid), from_kuid(&init_user_ns, audit_get_loginuid(current)), tty ? tty_name(tty) : "(none)", audit_get_sessionid(current)); audit_put_tty(tty); audit_log_task_context(ab); audit_log_format(ab, " comm="); audit_log_untrustedstring(ab, get_task_comm(comm, current)); audit_log_d_path_exe(ab, current->mm); audit_log_format(ab, "op=seccomp-logging"); audit_log_format(ab, " res=%u", res); where res above is a 1 for success and 0 for failure. Failure is likely to be due to not having the capability that allows setting the sysctl. > I hope this helps! Thanks! -Steve > diff --git a/include/linux/audit.h b/include/linux/audit.h > index af410d9..095b5dd 100644 > --- a/include/linux/audit.h > +++ b/include/linux/audit.h > @@ -304,12 +304,6 @@ static inline void audit_inode_child(struct inode > *parent, } > void audit_core_dumps(long signr); > > -static inline void audit_seccomp(unsigned long syscall, long signr, int > code) -{ > - if (audit_enabled && unlikely(!audit_dummy_context())) > - __audit_seccomp(syscall, signr, code); > -} > - > static inline void audit_ptrace(struct task_struct *t) > { > if (unlikely(!audit_dummy_context())) > @@ -502,8 +496,6 @@ static inline void audit_core_dumps(long signr) > { } > static inline void __audit_seccomp(unsigned long syscall, long signr, int > code) { } > -static inline void audit_seccomp(unsigned long syscall, long signr, int > code) -{ } > static inline int auditsc_get_stamp(struct audit_context *ctx, > struct timespec64 *t, unsigned int *serial) > { > diff --git a/kernel/seccomp.c b/kernel/seccomp.c > index 5f0dfb2ab..914a707 100644 > --- a/kernel/seccomp.c > +++ b/kernel/seccomp.c > @@ -590,12 +590,6 @@ static inline void seccomp_log(unsigned long syscall, > long signr, u32 action, */ > if (log) > return __audit_seccomp(syscall, signr, action); > - > - /* > - * Let the audit subsystem decide if the action should be audited based > - * on whether the current task itself is being audited. > - */ > - return audit_seccomp(syscall, signr, action); > } > > /* From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Limiting SECCOMP audit events Date: Fri, 15 Dec 2017 11:09:39 -0500 Message-ID: <2178350.DaTGirQ7H8@x2> References: <58203247.sCqcla2mis@x2> <1605a80e588.280e.85c95baa4474aabc7814e68940a78392@paul-moore.com> <20171215154713.GA16170@sec> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20171215154713.GA16170@sec> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Tyler Hicks Cc: Linux Audit List-Id: linux-audit@redhat.com On Friday, December 15, 2017 10:47:14 AM EST Tyler Hicks wrote: > > Looks good to me but two things: > > > > * Change the name of __audit_seccomp() to audit_seccomp() since we don't > > have two functions anymore. > > > > * Are we sure about removing the audit_enabled check? People got pretty > > upset when it wasn't there in the past. > > Do you have any references to the complaints so that we can understand > them better? I remember being surprised by commit 96368701 adding the > audit_enabled check (my fault for not watching the list closer) and > having to revert it in Ubuntu with a distro patch. > > > After sleeping on it for a night, I'm now unsure if the patch I sent in > this thread is what you guys really want. I'll go back to talking in > pseudocode. This is what we have in 4.14: > > 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 > > This is what the patch in this thread does: > > --- a/seccomp-log.pseudo > +++ b/seccomp-log.pseudo > @@ -6,7 +6,5 @@ > log > else if filter-requests-logging && action in actions_logged: > log > - else if audit_enabled && process-is-being-audited: > - log > else: > do not log > > Instead of that change, now I'm wondering if this is what you really > want: > > --- a/seccomp-log.pseudo > +++ b/seccomp-log.pseudo > @@ -6,7 +6,8 @@ > log > else if filter-requests-logging && action in actions_logged: > log > - else if audit_enabled && process-is-being-audited: > + else if audit_enabled && process-is-being-audited && > + action in actions_logged: > log > else: > do not log > > After refactoring the 'action in actions_logged' check, it would leave > us with this: > > if action == RET_ALLOW: > do not log > else if action not in actions_logged: > do not log Yeah, this would let us drop the trap return. While errno can lead to a lot of logging, in practice I just don't see them very often if ever. -Steve > else if action == RET_KILL: > log > else if action == RET_LOG: > log > else if filter-requests-logging: > log > else if audit_enabled && process-is-being-audited: > log > else: > do not log From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: Limiting SECCOMP audit events Date: Fri, 15 Dec 2017 15:54:16 -0500 Message-ID: <1605bf4c4c0.280e.85c95baa4474aabc7814e68940a78392@paul-moore.com> References: <58203247.sCqcla2mis@x2> <36cd827f-201c-8f76-2883-ecd930cbb1f4@canonical.com> <3499769.OM7YpPIT3e@x2> <20171214230629.GA451@sec> <1605a80e588.280e.85c95baa4474aabc7814e68940a78392@paul-moore.com> <20171215154713.GA16170@sec> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx02.extmail.prod.ext.phx2.redhat.com [10.5.110.26]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BD99265EB7 for ; Fri, 15 Dec 2017 20:54:23 +0000 (UTC) Received: from mail-io0-f193.google.com (mail-io0-f193.google.com [209.85.223.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 82B05883B8 for ; Fri, 15 Dec 2017 20:54:22 +0000 (UTC) Received: by mail-io0-f193.google.com with SMTP id s37so3947315ioe.10 for ; Fri, 15 Dec 2017 12:54:22 -0800 (PST) In-Reply-To: <20171215154713.GA16170@sec> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Tyler Hicks , Steve Grubb Cc: Linux Audit List-Id: linux-audit@redhat.com On December 15, 2017 10:47:17 AM Tyler Hicks wrote: > On 12/15/2017 08:08 AM, Paul Moore wrote: ... >> * Are we sure about removing the audit_enabled check? People got pretty >> upset when it wasn't there in the past. > > Do you have any references to the complaints so that we can understand > them better? I remember being surprised by commit 96368701 adding the > audit_enabled check (my fault for not watching the list closer) and > having to revert it in Ubuntu with a distro patch. I'm somewhat limited at the moment (replying by phone) so I can't my find it for you, but check the audit mailing list for the discussion. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Limiting SECCOMP audit events Date: Tue, 02 Jan 2018 15:03:32 -0500 Message-ID: <8105357.Wrpb4U9778@x2> References: <58203247.sCqcla2mis@x2> <20171214230629.GA451@sec> <3854763.JcSRc28zaO@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <3854763.JcSRc28zaO@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com Hello, I know people have been busy with the holidays and things...but I just wanted to mention I'm still seeing 100's of thousands of seccomp events hitting the audit logs every day. # ausearch --start today -m seccomp --raw | aureport -x --summary Executable Summary Report ================================= total file ================================= 209843 /usr/lib64/firefox/firefox 2196 /usr/lib64/qt5/libexec/QtWebEngineProcess Has anyone looked at it beyond pseudo code? -Steve On Friday, December 15, 2017 11:02:19 AM EST Steve Grubb wrote: > On Thursday, December 14, 2017 6:06:30 PM EST Tyler Hicks wrote: > > On 12/14/2017 09:19 AM, Steve Grubb wrote: > > > On Thursday, December 14, 2017 10:04:48 AM EST Tyler Hicks wrote: > > >> On 12/13/2017 05:58 PM, Steve Grubb wrote: > > >> > Over the last month, the amount of seccomp events in audit logs is > > >> > > > >> > sky-rocketing. I have over a million events in the last 2 days. Most > > >> > of > > >> > > > >> > this is generated by firefox and qt webkit. > > >> > > > >> > I am wondering if the audit package should ship a file for > > >> > > > >> > /usr/lib/sysctl.d/60-auditd.conf > > >> > > > >> > wherein it has > > >> > > > >> > kernel.seccomp.actions_logged = kill_process kill_thread errno > > >> > > >> I agree with Kees here. IMO, you only want "kill_process kill_thread" > > >> > > >> which is the default. > > > > > > The default appears to be all of the types of events without setting > > > kernel.seccomp.actions_logged. > > > > Ah, right. I didn't correctly remember the final implementation details. > > The default sysctl setting is to allow all actions except for RET_ALLOW > > to be logged. > > > > I think the easiest description of the logic is in the commit message of > > > > 59f5cf44a38284eb9e76270c786fb6cc62ef8ac4: > > 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 > > > > I think I originally misunderstood your first email in this thread. I > > thought you were saying that you were experiencing more seccomp audit > > events in 4.14 versus 4.13 and that you felt a regression had been > > introduced. After rereading, I think you're asking why you're getting > > seccomp RET_TRAP actions logged even though "trap" isn't in the > > actions_logged sysctl. > > Yes, exactly. I have been experiencing large amounts of SECCOMP events > starting with qt webkit in kde and thought 4.14 would finally let me tame > those events. I have opened a couple bz asking developers if they really > meant to go live with a policy that is experiencing so many denials. But > the consensus is this is intended. (But I think they also have not > actually tried to use their audit logs.) > > > The reason is because I didn't get clear direction from the audit > > folks about to do when audit is enabled and the process is being audited > > and, therefore, I didn't feel comfortable rocking the boat. In that > > situation, the decision to log is the same as it was in earlier kernels. > > Specifically, you're hitting the last "else if" conditional in the > > pseudocode above. > > And here I thought you were also seeing large numbers of seccomp events and > were making a way to control what gets logged. In any event, I think we > better understand each other now. :-) > > > If you're happy with having the actions_logged sysctl control whether or > > not to log seccomp actions taken for processes that are being audited, > > then I think the following (untested) patch should do exactly what you > > want. > > OK. Great. With developers starting to use the trap return value, audit > logs are getting swamped by benign events. We truly need a knob to > eliminate the noise from the signal. > > > I imagine that you'd also want seccomp to emit audit events whenever the > > value of the actions_logged sysctl is changed, which should be pretty > > easy > > to do. > > Sure. If you want to add it, then it should be roughly like this: > > struct tty_struct *tty; > const struct cred *cred; > struct audit_buffer *ab; > char comm[sizeof(current->comm)]; > > ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE); > if (unlikely(!ab)) > return; > > cred = current_cred(); > tty = audit_get_tty(current); > audit_log_format(ab, "pid=%d uid=%u auid=%u tty=%s ses=%u", > task_tgid_nr(current), > from_kuid(&init_user_ns, cred->uid), > from_kuid(&init_user_ns, > audit_get_loginuid(current)), > tty ? tty_name(tty) : "(none)", > audit_get_sessionid(current)); > audit_put_tty(tty); > audit_log_task_context(ab); > audit_log_format(ab, " comm="); > audit_log_untrustedstring(ab, get_task_comm(comm, current)); > audit_log_d_path_exe(ab, current->mm); > audit_log_format(ab, "op=seccomp-logging"); > > value. Numbers or mask is fine.> > > audit_log_format(ab, " res=%u", res); > > where res above is a 1 for success and 0 for failure. Failure is likely to > be due to not having the capability that allows setting the sysctl. > > > I hope this helps! > > Thanks! > > -Steve > > > diff --git a/include/linux/audit.h b/include/linux/audit.h > > index af410d9..095b5dd 100644 > > --- a/include/linux/audit.h > > +++ b/include/linux/audit.h > > @@ -304,12 +304,6 @@ static inline void audit_inode_child(struct inode > > *parent, } > > > > void audit_core_dumps(long signr); > > > > -static inline void audit_seccomp(unsigned long syscall, long signr, int > > code) -{ > > - if (audit_enabled && unlikely(!audit_dummy_context())) > > - __audit_seccomp(syscall, signr, code); > > -} > > - > > > > static inline void audit_ptrace(struct task_struct *t) > > { > > > > if (unlikely(!audit_dummy_context())) > > > > @@ -502,8 +496,6 @@ static inline void audit_core_dumps(long signr) > > > > { } > > static inline void __audit_seccomp(unsigned long syscall, long signr, > > int > > > > code) { } > > -static inline void audit_seccomp(unsigned long syscall, long signr, int > > code) -{ } > > > > static inline int auditsc_get_stamp(struct audit_context *ctx, > > > > struct timespec64 *t, unsigned int *serial) > > > > { > > > > diff --git a/kernel/seccomp.c b/kernel/seccomp.c > > index 5f0dfb2ab..914a707 100644 > > --- a/kernel/seccomp.c > > +++ b/kernel/seccomp.c > > @@ -590,12 +590,6 @@ static inline void seccomp_log(unsigned long > > syscall, > > long signr, u32 action, */ > > > > if (log) > > > > return __audit_seccomp(syscall, signr, action); > > > > - > > - /* > > - * Let the audit subsystem decide if the action should be audited based > > - * on whether the current task itself is being audited. > > - */ > > - return audit_seccomp(syscall, signr, action); > > > > } > > > > /* > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tyler Hicks Subject: Re: Limiting SECCOMP audit events Date: Tue, 2 Jan 2018 20:52:55 -0600 Message-ID: <25efc0c3-7532-ff66-9451-c2407fd467c1@canonical.com> References: <58203247.sCqcla2mis@x2> <20171214230629.GA451@sec> <3854763.JcSRc28zaO@x2> <8105357.Wrpb4U9778@x2> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1820423686873830052==" Return-path: In-Reply-To: <8105357.Wrpb4U9778@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb , linux-audit@redhat.com List-Id: linux-audit@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============1820423686873830052== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pKp0zcDM56gke2DMsVcYUU642IZpPrbqK" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pKp0zcDM56gke2DMsVcYUU642IZpPrbqK Content-Type: multipart/mixed; boundary="bBLvuzaSxlWK2IzSNJMvtZRRWxp2lDYWj"; protected-headers="v1" From: Tyler Hicks To: Steve Grubb , linux-audit@redhat.com Message-ID: <25efc0c3-7532-ff66-9451-c2407fd467c1@canonical.com> Subject: Re: Limiting SECCOMP audit events References: <58203247.sCqcla2mis@x2> <20171214230629.GA451@sec> <3854763.JcSRc28zaO@x2> <8105357.Wrpb4U9778@x2> In-Reply-To: <8105357.Wrpb4U9778@x2> --bBLvuzaSxlWK2IzSNJMvtZRRWxp2lDYWj Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 01/02/2018 02:03 PM, Steve Grubb wrote: > Hello, >=20 > I know people have been busy with the holidays and things...but I just = wanted=20 > to mention I'm still seeing 100's of thousands of seccomp events hittin= g the=20 > audit logs every day. >=20 > # ausearch --start today -m seccomp --raw | aureport -x --summary >=20 > Executable Summary Report > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > total file > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > 209843 /usr/lib64/firefox/firefox > 2196 /usr/lib64/qt5/libexec/QtWebEngineProcess >=20 > Has anyone looked at it beyond pseudo code? I started to throw together a quick couple of patches prior to the holidays but didn't finish. Things aren't looking good for the next few weeks for me so someone else should take over if it is important for 4.16= =2E Tyler >=20 > -Steve >=20 > On Friday, December 15, 2017 11:02:19 AM EST Steve Grubb wrote: >> On Thursday, December 14, 2017 6:06:30 PM EST Tyler Hicks wrote: >>> On 12/14/2017 09:19 AM, Steve Grubb wrote: >>>> On Thursday, December 14, 2017 10:04:48 AM EST Tyler Hicks wrote: >>>>> On 12/13/2017 05:58 PM, Steve Grubb wrote: >>>>>> Over the last month, the amount of seccomp events in audit logs is= >>>>>> >>>>>> sky-rocketing. I have over a million events in the last 2 days. Mo= st >>>>>> of >>>>>> >>>>>> this is generated by firefox and qt webkit. >>>>>> >>>>>> I am wondering if the audit package should ship a file for >>>>>> >>>>>> /usr/lib/sysctl.d/60-auditd.conf >>>>>> >>>>>> wherein it has >>>>>> >>>>>> kernel.seccomp.actions_logged =3D kill_process kill_thread errno >>>>> >>>>> I agree with Kees here. IMO, you only want "kill_process kill_threa= d" >>>>> >>>>> which is the default. >>>> >>>> The default appears to be all of the types of events without setting= >>>> kernel.seccomp.actions_logged. >>> >>> Ah, right. I didn't correctly remember the final implementation detai= ls. >>> The default sysctl setting is to allow all actions except for RET_ALL= OW >>> to be logged. >>> >>> I think the easiest description of the logic is in the commit message= of >>> >>> 59f5cf44a38284eb9e76270c786fb6cc62ef8ac4: >>> if action =3D=3D RET_ALLOW: >>> do not log >>> =20 >>> else if action =3D=3D RET_KILL && RET_KILL in actions_logged: >>> log >>> =20 >>> else if action =3D=3D RET_LOG && RET_LOG in actions_logged: >>> log >>> =20 >>> else if filter-requests-logging && action in actions_logged: >>> log >>> =20 >>> else if audit_enabled && process-is-being-audited: >>> log >>> =20 >>> else: >>> do not log >>> >>> I think I originally misunderstood your first email in this thread. I= >>> thought you were saying that you were experiencing more seccomp audit= >>> events in 4.14 versus 4.13 and that you felt a regression had been >>> introduced. After rereading, I think you're asking why you're getting= >>> seccomp RET_TRAP actions logged even though "trap" isn't in the >>> actions_logged sysctl. >> >> Yes, exactly. I have been experiencing large amounts of SECCOMP events= >> starting with qt webkit in kde and thought 4.14 would finally let me t= ame >> those events. I have opened a couple bz asking developers if they real= ly >> meant to go live with a policy that is experiencing so many denials. B= ut >> the consensus is this is intended. (But I think they also have not >> actually tried to use their audit logs.) >> >>> The reason is because I didn't get clear direction from the audit >>> folks about to do when audit is enabled and the process is being audi= ted >>> and, therefore, I didn't feel comfortable rocking the boat. In that >>> situation, the decision to log is the same as it was in earlier kerne= ls. >>> Specifically, you're hitting the last "else if" conditional in the >>> pseudocode above. >> >> And here I thought you were also seeing large numbers of seccomp event= s and >> were making a way to control what gets logged. In any event, I think w= e >> better understand each other now. :-) >> >>> If you're happy with having the actions_logged sysctl control whether= or >>> not to log seccomp actions taken for processes that are being audited= , >>> then I think the following (untested) patch should do exactly what yo= u >>> want. >> >> OK. Great. With developers starting to use the trap return value, audi= t >> logs are getting swamped by benign events. We truly need a knob to >> eliminate the noise from the signal. >> >>> I imagine that you'd also want seccomp to emit audit events whenever = the >>> value of the actions_logged sysctl is changed, which should be pretty= >>> easy >>> to do. >> >> Sure. If you want to add it, then it should be roughly like this: >> >> struct tty_struct *tty; >> const struct cred *cred; >> struct audit_buffer *ab; >> char comm[sizeof(current->comm)]; >> >> ab =3D audit_log_start(NULL, GFP_KERNEL, AUDIT_CONFIG_C= HANGE); >> if (unlikely(!ab)) >> return; >> >> cred =3D current_cred(); >> tty =3D audit_get_tty(current); >> audit_log_format(ab, "pid=3D%d uid=3D%u auid=3D%u tty=3D= %s ses=3D%u", >> task_tgid_nr(current), >> from_kuid(&init_user_ns, cred->uid), >> from_kuid(&init_user_ns, >> audit_get_loginuid(current)), >> tty ? tty_name(tty) : "(none)", >> audit_get_sessionid(current)); >> audit_put_tty(tty); >> audit_log_task_context(ab); >> audit_log_format(ab, " comm=3D"); >> audit_log_untrustedstring(ab, get_task_comm(comm, curre= nt)); >> audit_log_d_path_exe(ab, current->mm); >> audit_log_format(ab, "op=3Dseccomp-logging"); >> >> > value. Numbers or mask is fine.> >> >> audit_log_format(ab, " res=3D%u", res); >> >> where res above is a 1 for success and 0 for failure. Failure is likel= y to >> be due to not having the capability that allows setting the sysctl. >> >>> I hope this helps! >> >> Thanks! >> >> -Steve >> >>> diff --git a/include/linux/audit.h b/include/linux/audit.h >>> index af410d9..095b5dd 100644 >>> --- a/include/linux/audit.h >>> +++ b/include/linux/audit.h >>> @@ -304,12 +304,6 @@ static inline void audit_inode_child(struct inod= e >>> *parent, } >>> >>> void audit_core_dumps(long signr); >>> >>> -static inline void audit_seccomp(unsigned long syscall, long signr, = int >>> code) -{ >>> - if (audit_enabled && unlikely(!audit_dummy_context())) >>> - __audit_seccomp(syscall, signr, code); >>> -} >>> - >>> >>> static inline void audit_ptrace(struct task_struct *t) >>> { >>> =20 >>> if (unlikely(!audit_dummy_context())) >>> >>> @@ -502,8 +496,6 @@ static inline void audit_core_dumps(long signr) >>> >>> { } >>> static inline void __audit_seccomp(unsigned long syscall, long signr= , >>> int >>> >>> code) { } >>> -static inline void audit_seccomp(unsigned long syscall, long signr, = int >>> code) -{ } >>> >>> static inline int auditsc_get_stamp(struct audit_context *ctx, >>> =20 >>> struct timespec64 *t, unsigned int *serial) >>> =20 >>> { >>> >>> diff --git a/kernel/seccomp.c b/kernel/seccomp.c >>> index 5f0dfb2ab..914a707 100644 >>> --- a/kernel/seccomp.c >>> +++ b/kernel/seccomp.c >>> @@ -590,12 +590,6 @@ static inline void seccomp_log(unsigned long >>> syscall, >>> long signr, u32 action, */ >>> >>> if (log) >>> =09 >>> return __audit_seccomp(syscall, signr, action); >>> >>> - >>> - /* >>> - * Let the audit subsystem decide if the action should be audited=20 > based >>> - * on whether the current task itself is being audited. >>> - */ >>> - return audit_seccomp(syscall, signr, action); >>> >>> } >>> =20 >>> /* >> >> -- >> Linux-audit mailing list >> Linux-audit@redhat.com >> https://www.redhat.com/mailman/listinfo/linux-audit >=20 >=20 --bBLvuzaSxlWK2IzSNJMvtZRRWxp2lDYWj-- --pKp0zcDM56gke2DMsVcYUU642IZpPrbqK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJaTEWJAAoJENaSAD2qAscKheIP/icKHOu19r3OF9Fj/cmlT0+/ hOoqLQrt3VV/QL/t9TA4xaug4j8KaDFaVVOHfoHFywAAHaQcORw87wnRxd2Qxt+Q vwaGBGh7aWDQCBXXsFXXgQEazdpj9n0d9pFBD482WnjKew50syC4I4BOegBxG/WM 0CI96R1sLmTKlfrwlr/cS9EBR8bNECNQd6chS1s/iWySkGR13I8IusIqAttg/7y+ qtDsA3FUpEUsGGfskBPd541FhAWWcbyZkKxblTyyDZ0h0x3lDFZ/35Suomi6TAi9 XBd+tJUm8/aidUwb4FkJCJ3/l2QZjaS9FpXFIQaXlwCFgDnZRmMx8U5vFht6xfO6 hzgze7fsesDu3VhmYpWGIzMu2BB+XL8i4+bmcbCybkbILsyJ0Jm+hSDTuuP33kU+ UgZ8n0oVN9QUnStkz8CpWjNcX26Cj9KWqiJZN6t3jwjZ7JDAxVxPYKc4OfSb6amu 9vUe2xifKwVKEFOoSceJfXvWdJagWmYUG88VJ1aq9z8dnWOOCoAEx3RrhOglIUhZ izoQo2Kn8v/qNhyqhWMVizsFxccvkKqTY4cayQWePGLxhvJUV2ucWl7xS9BBTD6+ ctrxgOXO/pwKcijMy48h598/xhEmCPPZLbCqC7jIfJA7gG8sWeIpuQcDrGsmcRPQ +sfN+L8lWiYw8j0jezcK =pHX3 -----END PGP SIGNATURE----- --pKp0zcDM56gke2DMsVcYUU642IZpPrbqK-- --===============1820423686873830052== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1820423686873830052==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: Limiting SECCOMP audit events Date: Wed, 3 Jan 2018 09:25:12 -0500 Message-ID: References: <58203247.sCqcla2mis@x2> <20171214230629.GA451@sec> <3854763.JcSRc28zaO@x2> <8105357.Wrpb4U9778@x2> <25efc0c3-7532-ff66-9451-c2407fd467c1@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx01.extmail.prod.ext.phx2.redhat.com [10.5.110.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D88306376B for ; Wed, 3 Jan 2018 14:25:16 +0000 (UTC) Received: from mail-lf0-f67.google.com (mail-lf0-f67.google.com [209.85.215.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1993B81222 for ; Wed, 3 Jan 2018 14:25:15 +0000 (UTC) Received: by mail-lf0-f67.google.com with SMTP id f3so1836679lfe.4 for ; Wed, 03 Jan 2018 06:25:15 -0800 (PST) In-Reply-To: <25efc0c3-7532-ff66-9451-c2407fd467c1@canonical.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Tyler Hicks , Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Tue, Jan 2, 2018 at 9:52 PM, Tyler Hicks wrote: > On 01/02/2018 02:03 PM, Steve Grubb wrote: >> Hello, >> >> I know people have been busy with the holidays and things...but I just wanted >> to mention I'm still seeing 100's of thousands of seccomp events hitting the >> audit logs every day. >> >> # ausearch --start today -m seccomp --raw | aureport -x --summary >> >> Executable Summary Report >> ================================= >> total file >> ================================= >> 209843 /usr/lib64/firefox/firefox >> 2196 /usr/lib64/qt5/libexec/QtWebEngineProcess >> >> Has anyone looked at it beyond pseudo code? > > I started to throw together a quick couple of patches prior to the > holidays but didn't finish. Things aren't looking good for the next few > weeks for me so someone else should take over if it is important for 4.16. > > Tyler This is also on my todo list, but it sits behind fixing one last libseccomp bug and getting a new release out. I made some good progress on the libseccomp bug right before the holiday, but I think there is still a days worth of work left before it is ready to be merged. I'm also traveling for the next week so I doubt I'll have any serious time to devote to the kernel patch(es). I can't remember what Tyler's last thought was on the logic, but I imagine I'll just wait until I see some patches to review/merge, or I can go back in the thread if I happen to have time before anyone else. Also, to set expectations, since we are currently at -rc6, this is likely going to need to wait until 4.17 at the earliest as I generally don't like merging new functionality in the last week or two before the merge window. Also (part two), we should add a test case to the audit-testsuite for any new knobs that affect the SECCOMP records. -- paul moore www.paul-moore.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Limiting SECCOMP audit events Date: Tue, 17 Apr 2018 18:54:28 -0400 Message-ID: <1644244.YUtc8I8vVY@x2> References: <58203247.sCqcla2mis@x2> <25efc0c3-7532-ff66-9451-c2407fd467c1@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Paul Moore Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Hello, Ping? SECCOMP events are still flooding the system. Can we do something hackish to turn this off until a better solution can be created? Thanks, -Steve On Wednesday, January 3, 2018 9:25:12 AM EDT Paul Moore wrote: > On Tue, Jan 2, 2018 at 9:52 PM, Tyler Hicks wrote: > > On 01/02/2018 02:03 PM, Steve Grubb wrote: > >> Hello, > >> > >> I know people have been busy with the holidays and things...but I just > >> wanted to mention I'm still seeing 100's of thousands of seccomp events > >> hitting the audit logs every day. > >> > >> # ausearch --start today -m seccomp --raw | aureport -x --summary > >> > >> Executable Summary Report > >> ================================= > >> total file > >> ================================= > >> 209843 /usr/lib64/firefox/firefox > >> 2196 /usr/lib64/qt5/libexec/QtWebEngineProcess > >> > >> Has anyone looked at it beyond pseudo code? > > > > I started to throw together a quick couple of patches prior to the > > holidays but didn't finish. Things aren't looking good for the next few > > weeks for me so someone else should take over if it is important for > > 4.16. > > > > Tyler > > This is also on my todo list, but it sits behind fixing one last > libseccomp bug and getting a new release out. I made some good > progress on the libseccomp bug right before the holiday, but I think > there is still a days worth of work left before it is ready to be > merged. I'm also traveling for the next week so I doubt I'll have any > serious time to devote to the kernel patch(es). > > I can't remember what Tyler's last thought was on the logic, but I > imagine I'll just wait until I see some patches to review/merge, or I > can go back in the thread if I happen to have time before anyone else. > > Also, to set expectations, since we are currently at -rc6, this is > likely going to need to wait until 4.17 at the earliest as I generally > don't like merging new functionality in the last week or two before > the merge window. > > Also (part two), we should add a test case to the audit-testsuite for > any new knobs that affect the SECCOMP records. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: Limiting SECCOMP audit events Date: Tue, 17 Apr 2018 21:57:10 -0400 Message-ID: References: <58203247.sCqcla2mis@x2> <25efc0c3-7532-ff66-9451-c2407fd467c1@canonical.com> <1644244.YUtc8I8vVY@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx04.extmail.prod.ext.phx2.redhat.com [10.5.110.28]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CED8617D30 for ; Wed, 18 Apr 2018 01:57:23 +0000 (UTC) Received: from mail-lf0-f65.google.com (mail-lf0-f65.google.com [209.85.215.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 90EB685540 for ; Wed, 18 Apr 2018 01:57:12 +0000 (UTC) Received: by mail-lf0-f65.google.com with SMTP id p142-v6so228786lfd.6 for ; Tue, 17 Apr 2018 18:57:12 -0700 (PDT) In-Reply-To: <1644244.YUtc8I8vVY@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Tue, Apr 17, 2018 at 6:54 PM, Steve Grubb wrote: > Hello, > > Ping? SECCOMP events are still flooding the system. Can we do something > hackish to turn this off until a better solution can be created? Pong? The only workarounds I can think of would be to disable audit or create a filter rule excluding auditing for the noisy process. I've never tried the latter, but I'm pretty sure it would work. > On Wednesday, January 3, 2018 9:25:12 AM EDT Paul Moore wrote: >> On Tue, Jan 2, 2018 at 9:52 PM, Tyler Hicks wrote: >> > On 01/02/2018 02:03 PM, Steve Grubb wrote: >> >> Hello, >> >> >> >> I know people have been busy with the holidays and things...but I just >> >> wanted to mention I'm still seeing 100's of thousands of seccomp events >> >> hitting the audit logs every day. >> >> >> >> # ausearch --start today -m seccomp --raw | aureport -x --summary >> >> >> >> Executable Summary Report >> >> ================================= >> >> total file >> >> ================================= >> >> 209843 /usr/lib64/firefox/firefox >> >> 2196 /usr/lib64/qt5/libexec/QtWebEngineProcess >> >> >> >> Has anyone looked at it beyond pseudo code? >> > >> > I started to throw together a quick couple of patches prior to the >> > holidays but didn't finish. Things aren't looking good for the next few >> > weeks for me so someone else should take over if it is important for >> > 4.16. >> > >> > Tyler >> >> This is also on my todo list, but it sits behind fixing one last >> libseccomp bug and getting a new release out. I made some good >> progress on the libseccomp bug right before the holiday, but I think >> there is still a days worth of work left before it is ready to be >> merged. I'm also traveling for the next week so I doubt I'll have any >> serious time to devote to the kernel patch(es). >> >> I can't remember what Tyler's last thought was on the logic, but I >> imagine I'll just wait until I see some patches to review/merge, or I >> can go back in the thread if I happen to have time before anyone else. >> >> Also, to set expectations, since we are currently at -rc6, this is >> likely going to need to wait until 4.17 at the earliest as I generally >> don't like merging new functionality in the last week or two before >> the merge window. >> >> Also (part two), we should add a test case to the audit-testsuite for >> any new knobs that affect the SECCOMP records. > > > > -- paul moore www.paul-moore.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tyler Hicks Subject: Re: Limiting SECCOMP audit events Date: Tue, 24 Apr 2018 19:00:46 -0500 Message-ID: References: <58203247.sCqcla2mis@x2> <25efc0c3-7532-ff66-9451-c2407fd467c1@canonical.com> <1644244.YUtc8I8vVY@x2> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2561870314193518774==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Paul Moore , Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============2561870314193518774== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="M1SRKnWMbQjpVIKY4q5LcYxA22SmEmdcj" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --M1SRKnWMbQjpVIKY4q5LcYxA22SmEmdcj Content-Type: multipart/mixed; boundary="CaQxvgCQE3nJ0ddAdvxyugatzBZFNi9Pl"; protected-headers="v1" From: Tyler Hicks To: Paul Moore , Steve Grubb Cc: linux-audit@redhat.com Message-ID: Subject: Re: Limiting SECCOMP audit events References: <58203247.sCqcla2mis@x2> <25efc0c3-7532-ff66-9451-c2407fd467c1@canonical.com> <1644244.YUtc8I8vVY@x2> In-Reply-To: --CaQxvgCQE3nJ0ddAdvxyugatzBZFNi9Pl Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/17/2018 08:57 PM, Paul Moore wrote: > On Tue, Apr 17, 2018 at 6:54 PM, Steve Grubb wrote:= >> Hello, >> >> Ping? SECCOMP events are still flooding the system. Can we do somethi= ng >> hackish to turn this off until a better solution can be created? >=20 > Pong? >=20 > The only workarounds I can think of would be to disable audit or > create a filter rule excluding auditing for the noisy process. I've > never tried the latter, but I'm pretty sure it would work. I've pushed two branches which have slightly different behaviors. They only differ by the last patch in each branch. The tree is here: https://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/linux.git/ 1) seccomp-auditing/option-1-consistent-behavior This branch removes all special casing around audited processes. The decision on whether or not to audit an action no longer considers whether or not the process is being audited. RET_TRAP, RET_TRACE, and RET_ERRNO actions will only be logged if the application loads the filter with the SECCOMP_FILTER_FLAG_LOG bit set. The admin has the final say via the kernel.seccomp.actions_logged sysctl. 2) seccomp-auditing/option-2-honor-sysctl This branch continues to special case audited processes. The decision to log RET_TRAP, RET_TRACE, and RET_ERRNO actions depends on if the SECCOMP_FILTER_FLAG_LOG bit being set OR if the process is being audited. The admin has the final say via the kernel.seccomp.actions_logged sysctl. I prefer option #1. Play with both implementations and let me know what works best for your requirements. Both branches share the same underlying patches for emitting audit records on writes to the kernel.seccomp.actions_logged sysctl. Tyler >=20 >> On Wednesday, January 3, 2018 9:25:12 AM EDT Paul Moore wrote: >>> On Tue, Jan 2, 2018 at 9:52 PM, Tyler Hicks w= rote: >>>> On 01/02/2018 02:03 PM, Steve Grubb wrote: >>>>> Hello, >>>>> >>>>> I know people have been busy with the holidays and things...but I j= ust >>>>> wanted to mention I'm still seeing 100's of thousands of seccomp ev= ents >>>>> hitting the audit logs every day. >>>>> >>>>> # ausearch --start today -m seccomp --raw | aureport -x --summary >>>>> >>>>> Executable Summary Report >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> total file >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> 209843 /usr/lib64/firefox/firefox >>>>> 2196 /usr/lib64/qt5/libexec/QtWebEngineProcess >>>>> >>>>> Has anyone looked at it beyond pseudo code? >>>> >>>> I started to throw together a quick couple of patches prior to the >>>> holidays but didn't finish. Things aren't looking good for the next = few >>>> weeks for me so someone else should take over if it is important for= >>>> 4.16. >>>> >>>> Tyler >>> >>> This is also on my todo list, but it sits behind fixing one last >>> libseccomp bug and getting a new release out. I made some good >>> progress on the libseccomp bug right before the holiday, but I think >>> there is still a days worth of work left before it is ready to be >>> merged. I'm also traveling for the next week so I doubt I'll have an= y >>> serious time to devote to the kernel patch(es). >>> >>> I can't remember what Tyler's last thought was on the logic, but I >>> imagine I'll just wait until I see some patches to review/merge, or I= >>> can go back in the thread if I happen to have time before anyone else= =2E >>> >>> Also, to set expectations, since we are currently at -rc6, this is >>> likely going to need to wait until 4.17 at the earliest as I generall= y >>> don't like merging new functionality in the last week or two before >>> the merge window. >>> >>> Also (part two), we should add a test case to the audit-testsuite for= >>> any new knobs that affect the SECCOMP records. >> >> >> >> >=20 >=20 >=20 --CaQxvgCQE3nJ0ddAdvxyugatzBZFNi9Pl-- --M1SRKnWMbQjpVIKY4q5LcYxA22SmEmdcj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEPgU+cN5AsTrekT5+1pIAPaoCxwoFAlrfxS4ACgkQ1pIAPaoC xwodSQ//YAX2BBB553BYQ/AAv1TriTB0zWezYfZhNBy4uIQEKvez6/iQd+V5XaOu lvQwkaz/jbZ167zULHJ3ADz+FsYWacilgp0Vp84unMa4mqgEOHSGcx/sTbUfQZjL 8m2kXWMs5E95Q6AKaGS8Q48lz3XnBvr+MI4+BTwE1qvZfrOIi3KlRhdVTCXpNFPC XdlFd9sbi36i8NqJoR9aAWDCwjWKlFXq8SmbclpC9tuC8nHZv0yNM9AlZnKnY93K K5L1J+vidBudeLwXoGR/RmCOdh6LWzedSF1iHpBuhniiRkuYqqNOMMJ6A2tRaRyS XbXfEet+Gdv6jWWsdLB6PSAMQhJQnilcT0o9DztWpme6luz2LbiNjCoPu5RAiATh 37LZorJg/AXEktnkEqHtvrJ/+eTIa4Qi2SdkDBXWxevuEyuwICmkGo7PKmqRIsbL JxDqjtexhHlrJHUIWgyBrMv9EduYk5A0L68+R9KORG2TNLONR9dy9OTuNIlu6ju6 9ISJvvDjjTyMgds6NWyECJHp9lXk6Ob8KZj96p4rFogbxgB+DpS5sL7LyY/62bm8 xQzlmLJKyl2NVZtTdjaSvYzb/g9hfjSlHDlqP2jYEqp1y/0Y1BUkE+ZDg80jrStq pE3X8vseF2VXCCCAUOV8brZMp7WEuHwo2Z9gS85UqISklB++9Nk= =By/6 -----END PGP SIGNATURE----- --M1SRKnWMbQjpVIKY4q5LcYxA22SmEmdcj-- --===============2561870314193518774== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============2561870314193518774==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: Limiting SECCOMP audit events Date: Thu, 26 Apr 2018 10:41:24 -0400 Message-ID: References: <58203247.sCqcla2mis@x2> <25efc0c3-7532-ff66-9451-c2407fd467c1@canonical.com> <1644244.YUtc8I8vVY@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx18.extmail.prod.ext.phx2.redhat.com [10.5.110.47]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 034E417B87 for ; Thu, 26 Apr 2018 14:41:38 +0000 (UTC) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B855730001D3 for ; Thu, 26 Apr 2018 14:41:26 +0000 (UTC) Received: by mail-lf0-f47.google.com with SMTP id m18-v6so13824488lfb.0 for ; Thu, 26 Apr 2018 07:41:26 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Tyler Hicks Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Tue, Apr 24, 2018 at 8:00 PM, Tyler Hicks wrote: > On 04/17/2018 08:57 PM, Paul Moore wrote: >> On Tue, Apr 17, 2018 at 6:54 PM, Steve Grubb wrote: >>> Hello, >>> >>> Ping? SECCOMP events are still flooding the system. Can we do something >>> hackish to turn this off until a better solution can be created? >> >> Pong? >> >> The only workarounds I can think of would be to disable audit or >> create a filter rule excluding auditing for the noisy process. I've >> never tried the latter, but I'm pretty sure it would work. > > I've pushed two branches which have slightly different behaviors. They > only differ by the last patch in each branch. The tree is here: > > https://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/linux.git/ > > 1) seccomp-auditing/option-1-consistent-behavior > This branch removes all special casing around audited processes. The > decision on whether or not to audit an action no longer considers > whether or not the process is being audited. RET_TRAP, RET_TRACE, > and RET_ERRNO actions will only be logged if the application loads > the filter with the SECCOMP_FILTER_FLAG_LOG bit set. The admin has > the final say via the kernel.seccomp.actions_logged sysctl. > > 2) seccomp-auditing/option-2-honor-sysctl > This branch continues to special case audited processes. The decision > to log RET_TRAP, RET_TRACE, and RET_ERRNO actions depends on if the > SECCOMP_FILTER_FLAG_LOG bit being set OR if the process is being > audited. The admin has the final say via the > kernel.seccomp.actions_logged sysctl. > > I prefer option #1. Play with both implementations and let me know what > works best for your requirements. Both branches share the same > underlying patches for emitting audit records on writes to the > kernel.seccomp.actions_logged sysctl. Looking quickly at the two branches, I think I prefer the option-1-consistent-behavior approach, although some changes are needed. Could you post those patches to list for review/discussion? -- paul moore www.paul-moore.com