Re: [PATCH] audit: set context->dummy even when audit is off
On 31 Oct 2019, at 19:27, Paul Moore wrote:
On Thu, Oct 31, 2019 at 12:40 PM Chris Mason <clm(a)fb.com>
wrote:
[ ... ]
Hi Chris,
This is a rather hasty email as I'm at a conference right now, but I
wanted to convey that I'm not opposed to making sure that the NTP
records obey the audit configuration (that was the original intent
after all), I think it is just that we are all a little confused as to
why you are seeing the NTP records *and*only* the NTP records.
This part is harder to nail down because there's a window during boot
where journald has enabled audit but chef hasn't yet run in and turned
it off, so we get a lot of logs early and then mostly ntp after that.
I feel like the answer is that most of the places that actually log
audit records are also checking audit_enabled. Poking a bit with
cscope, we're not using most of the places that rely only on
audit_dummy_context().
I grabbed the last week or so of audit: lines from netconsole, and most
of them (73%) were type 1130 from early in the boot. These are the ones
turned off when chef runs. Another big chunk were the one time audit
initialized message from boot, mostly reflecting our rollout of the new
kernel. After that it was ntp and couple of random things like
fanotify.
It's been a while, but I thought we suggested Dave try running
'auditctl -a never,task' to see if that would solve his problem and I
believe his answer was no, which confused me a bit as the
audit_filter_task() call in audit_alloc() should see that rule and
return a state of AUDIT_DISABLED which not only prevents audit_alloc()
from allocating an audit_context (and remember if the audit_context is
NULL then audit_dummy_context() returns true), but it also clears the
TIF_SYSCALL_AUDIT flag (which I'm guessing you also want).
Thanks for the reminder on this part, I meant to test it. Yes, auditctl
-a never,task does stop the messages, even without my patch applied.
-chris