Re: Limiting SECCOMP audit events

On Tue, Apr 17, 2018 at 6:54 PM, Steve Grubb <sgrubb(a)redhat.com&gt; 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 <tyhicks(a)canonical.com&gt; 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. > > > >