All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]



  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.