Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAHC9VhTyz7fd+iQaymVXUGFe3ZA5Z_WkJeY_snDYiZ9GP6gCOA@mail.gmail.com>
 <20191031163931.1102669-1-clm@fb.com> <CAHC9VhRwRSGa5JSL0=cXxG-oOg9jUve9OEYyTCqTxzr=aMdGxg@mail.gmail.com>
 <B63048C4-3158-453B-859A-C5574AACDC36@fb.com> <CAHC9VhR92Ade8_d1UnTy4_hJDxmwZPU31eubnrq=ejPBjkTS4w@mail.gmail.com>
 <5E08422A-BFE2-4515-A804-3DB42B7D8550@fb.com>
In-Reply-To: <5E08422A-BFE2-4515-A804-3DB42B7D8550@fb.com>
From:   Paul Moore <paul@paul-moore.com>
Date:   Mon, 4 Nov 2019 19:45:13 -0500
Message-ID: <CAHC9VhSX=BN_9hNO3TO-ZBpxqphuM-xVNAQHcqVuO50Yo8C-Rg@mail.gmail.com>
Subject: Re: [PATCH] audit: set context->dummy even when audit is off
To:     Chris Mason <clm@fb.com>
Cc:     Eric Paris <eparis@redhat.com>,
        Dave Jones <davej@codemonkey.org.uk>,
        "linux-audit@redhat.com" <linux-audit@redhat.com>,
        Kyle McMartin <jkkm@fb.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Nov 4, 2019 at 7:39 PM Chris Mason <clm@fb.com> wrote:
> On 4 Nov 2019, at 19:15, Paul Moore wrote:
>
> > On Fri, Nov 1, 2019 at 9:24 AM Chris Mason <clm@fb.com> wrote:
> >> On 31 Oct 2019, at 19:27, Paul Moore wrote:
> >>> 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.
> >
> > I'm glad to hear that worked, I was going to be *very* confused if you
> > came back and said you were still seeing NTP records.
> >
> > I would suggest that regardless of what happens with audit_enabled you
> > likely want to keep this audit rule as part of your boot
> > configuration, not only does it squelch the audit records, but it
> > should improve performance as well (at the cost of no syscall
> > auditing).  A number of Linux distros have this as their default at
> > boot.
> >
>
> Definitely, we'll be testing auditctl -a never,task internally.  Before
> we went down that path I wanted to fully understand what was going on,
> but I think all the big questions have been answered at this point.

Yes, that is why we didn't do anything earlier with Dave's reports; we
couldn't reconcile the results with the code, and the lack of other
similar problem reports made me suspicious.  As you said, we
understand things a bit better now.

> I'm happy to try variations on my patch, but if you want to include it,
> please do remember that I've really only tested it with auditing off.

Understood.  FWIW, I'm not overly in love with the approach in the
patch you posted, but I haven't looked too seriously into alternatives
thus far.  I expect with most everyone running with the "never" audit
rule installed this solves this just fine for the time being.

-- 
paul moore
www.paul-moore.com