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;
Date:   Thu, 11 Apr 2019 14:22:47 +0200
From:   Steve Grubb <sgrubb@redhat.com>
To:     Richard Guy Briggs <rgb@redhat.com>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Linux-Audit Mailing List <linux-audit@redhat.com>,
        Paul Moore <paul@paul-moore.com>, omosnace@redhat.com,
        eparis@parisplace.org, ebiederm@xmission.com, oleg@redhat.com
Subject: Re: [PATCH ghak111 V1] audit: deliver siginfo regarless of syscall
Message-ID: <20190411142247.1a7a3639@ivy-bridge>
In-Reply-To: <20190409155728.dfp4qwseo6jxdmqr@madcap2.tricolour.ca>
References: <c7b092894ac6d611f8c5083e712da41e6685f94a.1554781852.git.rgb@redhat.com>
        <20190409080138.745d18a1@ivy-bridge>
        <20190409140259.n4t6rxb24eu3uzvp@madcap2.tricolour.ca>
        <20190409173716.1a0308fb@ivy-bridge>
        <20190409155728.dfp4qwseo6jxdmqr@madcap2.tricolour.ca>
Organization: Red Hat
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 9 Apr 2019 11:57:28 -0400
Richard Guy Briggs <rgb@redhat.com> wrote:

> On 2019-04-09 17:37, Steve Grubb wrote:
> > On Tue, 9 Apr 2019 10:02:59 -0400
> > Richard Guy Briggs <rgb@redhat.com> wrote:
> >   
> > > On 2019-04-09 08:01, Steve Grubb wrote:  
> > > > On Mon,  8 Apr 2019 23:52:29 -0400 Richard Guy Briggs
> > > > <rgb@redhat.com> wrote:    
> > > > > When a process signals the audit daemon (shutdown, rotate,
> > > > > resume, reconfig) but syscall auditing is not enabled, we
> > > > > still want to know the identity of the process sending the
> > > > > signal to the audit daemon.    
> > > > 
> > > > Why? If syscall auditing is disabled, then there is no
> > > > requirement to provide anything. What is the real problem that
> > > > you are seeing?    
> > > 
> > > Shutdown messages with -1 in them rather than the real values.  
> > 
> > OK. We can fix that by patching auditd to see if auditing is enabled
> > before requesting signal info. If auditing is disabled, the proper
> > action is for the kernel to ignore any audit userspace messages
> > except the configuration commands.  
> 
> If auditing is disabled in the kernel, none of this is trackable.  It
> is for those as yet unsupported arches that can run audit enabled but
> without auditsyscall support.

Ok. I suppose this is useful for this use case. No further objections.

-Steve