Limiting SECCOMP audit events

[Tyler Hicks]

On 04/17/2018 08:57 PM, Paul Moore wrote:
> On Tue, Apr 17, 2018 at 6:54 PM, Steve Grubb <sgrubb at redhat.com> 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 <tyhicks at canonical.com> 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.
>>
>>
>>
>>
> 
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20180424/a1a7aceb/attachment.sig>