From: Dave Jones <davej@codemonkey.org.uk>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Cc: Paul Moore <paul@paul-moore.com>, Eric Paris <eparis@redhat.com>
Subject: ntp audit spew.
Date: Mon, 23 Sep 2019 11:50:41 -0400 [thread overview]
Message-ID: <20190923155041.GA14807@codemonkey.org.uk> (raw)
I have some hosts that are constantly spewing audit messages like so:
[46897.591182] audit: type=1333 audit(1569250288.663:220): op=offset old=2543677901372 new=2980866217213
[46897.591184] audit: type=1333 audit(1569250288.663:221): op=freq old=-2443166611284 new=-2436281764244
[48850.604005] audit: type=1333 audit(1569252241.675:222): op=offset old=1850302393317 new=3190241577926
[48850.604008] audit: type=1333 audit(1569252241.675:223): op=freq old=-2436281764244 new=-2413071187316
[49926.567270] audit: type=1333 audit(1569253317.638:224): op=offset old=2453141035832 new=2372389610455
[49926.567273] audit: type=1333 audit(1569253317.638:225): op=freq old=-2413071187316 new=-2403561671476
This gets emitted every time ntp makes an adjustment, which is apparently very frequent on some hosts.
Audit isn't even enabled on these machines.
# auditctl -l
No rules
# auditctl -s
enabled 0
failure 1
pid 0
rate_limit 0
backlog_limit 64
lost 0
backlog 0
loginuid_immutable 0 unlocked
Asides from the log spew, why is this code doing _anything_ when audit
isn't enabled ?
Something like this:
diff --git a/kernel/audit.c b/kernel/audit.c
index da8dc0db5bd3..1291d826c024 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -2340,6 +2340,9 @@ void audit_log(struct audit_context *ctx, gfp_t gfp_mask, int type,
struct audit_buffer *ab;
va_list args;
+ if (audit_initialized != AUDIT_INITIALIZED)
+ return;
+
ab = audit_log_start(ctx, gfp_mask, type);
if (ab) {
va_start(args, fmt);
Might silence the spew, but I'm concerned that the amount of work that
audit is doing on an unconfigured machine might warrant further
investigation.
("turn off CONFIG_AUDIT" isn't an option unfortunately, as this is a
one-size-fits-all kernel that runs on some other hosts that /do/ have
audit configured)
Dave
next reply other threads:[~2019-09-23 16:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-23 15:50 Dave Jones [this message]
2019-09-23 16:14 ` ntp audit spew Paul Moore
2019-09-23 16:58 ` Dave Jones
2019-09-23 18:57 ` Paul Moore
2019-09-23 19:49 ` Dave Jones
2019-09-23 19:49 ` Eric Paris
2019-09-24 2:39 ` Paul Moore
2019-09-23 21:00 ` Richard Guy Briggs
2019-09-24 3:01 ` Paul Moore
2019-09-24 13:50 ` Richard Guy Briggs
2019-09-24 17:05 ` Paul Moore
2019-09-26 15:50 ` Paul Moore
2019-09-24 13:19 ` Steve Grubb
2019-09-24 17:01 ` Paul Moore
2019-10-31 16:39 ` [PATCH] audit: set context->dummy even when audit is off Chris Mason
2019-10-31 23:27 ` Paul Moore
2019-11-01 13:24 ` Chris Mason
2019-11-01 14:16 ` Steve Grubb
2019-11-01 15:55 ` Chris Mason
2019-11-05 0:15 ` Paul Moore
2019-11-05 0:39 ` Chris Mason
2019-11-05 0:45 ` 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=20190923155041.GA14807@codemonkey.org.uk \
--to=davej@codemonkey.org.uk \
--cc=eparis@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--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