From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: Re: configuration for busy docker host
Date: Mon, 20 Aug 2018 13:48:51 -0400 [thread overview]
Message-ID: <1898518.JS7Fg7ejBs@x2> (raw)
In-Reply-To: <28615add-906a-b86a-2d02-db5ae33898d9@genkgo.nl>
On Monday, August 20, 2018 5:56:04 AM EDT Frederik Bosch wrote:
> As I have not found a location anywhere else on the web, I am sending my
> question to this list. I have an Ubuntu 18.04 machine with auditd and it
> acts as a Docker Host machine. I have hardened the system via this
> package: https://github.com/konstruktoid/hardening which installs auditd
> with the configuration to be found here:
> https://github.com/konstruktoid/hardening/blob/master/misc/audit.rules.
These rules could be improved upon by condensing:
# File deletions
# Capture all unauthorized file accesses
# Capture all failures to access on critical elements
# Permissions
down to 2 rules in each, 4 for the second one. That, however, is not the
actual problem. My guess is that it is capturing way more information than is
necessary.
> The problems I have are related to the directives -f and -b. The
> hardening package uses -b 8192 and -f 2. That results in a kernel panic
> very quickly because of audit backlog limit exceeded, and that causes a
> reboot of the system. Now I wonder what a good configuration would be. I
> started reading on the subject and read that -f 2 is probably the best
> for security reasons. However, I do not want to have a system that
> panics very quickly and reboots.
I'd say that you need to run:
aureport --start today --key --summary
and see what rule is triggering all the events. Do you really want all
deletes? Or just deletes in a specific directory? Do you really want to know
that a user changed dir permissions on a file in their homedir?
> Should I simply increase the backlog to much higher numbers? Or should I
> change -f to not cause a kernel panic? Or am I missing something and
> should I change some other configuration? Thanks for your help.
For the moment change -f not to cause a kernel panic. I think the rules are
probably too aggressive.
-Steve
next prev parent reply other threads:[~2018-08-20 17:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-20 9:56 configuration for busy docker host Frederik Bosch
2018-08-20 14:10 ` Frederik Bosch
2018-08-20 17:48 ` Steve Grubb [this message]
2018-08-22 11:40 ` Frederik Bosch
2018-08-22 12:42 ` Steve Grubb
2018-08-22 14:49 ` Frederik Bosch
2018-08-23 14:18 ` Steve Grubb
2018-08-23 16:01 ` Frederik Bosch
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=1898518.JS7Fg7ejBs@x2 \
--to=sgrubb@redhat.com \
--cc=linux-audit@redhat.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.