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. Tyler > >> 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. >> >> >> >> > > >