From: Steve Grubb <sgrubb@redhat.com>
To: Paul Moore <paul@paul-moore.com>
Cc: Linux Audit <linux-audit@redhat.com>
Subject: Re: Limiting SECCOMP audit events
Date: Wed, 13 Dec 2017 22:30:21 -0500 [thread overview]
Message-ID: <17198747.0Wk1AduiP0@x2> (raw)
In-Reply-To: <CAHC9VhRSUaVcSykVL2YOP_kJU_UiY0xjsmeLBy63SpKGMmYmpA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3220 bytes --]
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
[-- Attachment #1.2: Type: text/html, Size: 13801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2017-12-14 3:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-13 23:58 Limiting SECCOMP audit events Steve Grubb
2017-12-14 0:16 ` Kees Cook
2017-12-14 0:31 ` Steve Grubb
2017-12-14 1:43 ` Paul Moore
2017-12-14 3:30 ` Steve Grubb [this message]
2017-12-14 12:42 ` Paul Moore
2017-12-14 15:29 ` Steve Grubb
2017-12-14 15:04 ` Tyler Hicks
2017-12-14 15:19 ` Steve Grubb
2017-12-14 23:06 ` Tyler Hicks
2017-12-14 23:16 ` Kees Cook
2017-12-15 14:08 ` Paul Moore
2017-12-15 15:47 ` Tyler Hicks
2017-12-15 16:09 ` Steve Grubb
2017-12-15 20:54 ` Paul Moore
2017-12-15 16:02 ` Steve Grubb
2018-01-02 20:03 ` Steve Grubb
2018-01-03 2:52 ` Tyler Hicks
2018-01-03 14:25 ` Paul Moore
2018-04-17 22:54 ` Steve Grubb
2018-04-18 1:57 ` Paul Moore
2018-04-25 0:00 ` Tyler Hicks
2018-04-26 14:41 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17198747.0Wk1AduiP0@x2 \
--to=sgrubb@redhat.com \
--cc=linux-audit@redhat.com \
--cc=paul@paul-moore.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox