linux-kernel - Re: [PATCH] audit: set context->dummy even when audit is off

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <B63048C4-3158-453B-859A-C5574AACDC36@fb.com>
Date:   Fri, 1 Nov 2019 13:24:17 +0000
From:   Chris Mason <clm@...com>
To:     Paul Moore <paul@...l-moore.com>
CC:     Eric Paris <eparis@...hat.com>,
        Dave Jones <davej@...emonkey.org.uk>,
        "linux-audit@...hat.com" <linux-audit@...hat.com>,
        Kyle McMartin <jkkm@...com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: 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@...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