[PATCH ghak111 V1] audit: deliver siginfo regarless of syscall

[Richard Guy Briggs]

On 2019-04-09 19:25, Eric W. Biederman wrote:
> Minor nit about the description of this patch (as I presume it will need
> to respun).
> 
> You are talking about audit signal information.  You are not talking
> about struct siginfo (aka siginfo_t).  The structure siginfo_t is part
> of posix and userspace ABI and is part of the stack frame for a
> delivered signal.
> 
> The summary had me thinking you were messing with when siginfo is
> collected and delivered to userspace.

Got it.  I'll switch it to at least sig_info if not something even a bit
more descriptive and less confusing.

> Richard Guy Briggs <rgb at redhat.com> writes:
> > On 2019-04-09 17:37, Steve Grubb wrote:
> >> On Tue, 9 Apr 2019 10:02:59 -0400
> >> Richard Guy Briggs <rgb at 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 at 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.
> >
> > Here's a current sample with CONFIG_AUDIT and ~CONFIG_AUDITSYSCALL
> > configured, note "auid=" and "pid=":
> >
> > 	killall -HUP auditd
> > 	type=DAEMON_CONFIG msg=audit(2019-04-09 11:37:04.508:3266) op=reconfigure state=changed auid=unset pid=-1 subj=? res=success
> >
> > 	killall -TERM auditd
> > 	type=DAEMON_END msg=audit(2019-04-09 11:51:50.441:5709) : op=terminate auid=unset pid=-1 subj=? res=success 
> > 	
> > and the same with the patch applied:
> >
> > 	killall -HUP auditd
> > 	type=DAEMON_CONFIG msg=audit(2019-04-09 11:42:40.851:8924) op=reconfigure state=changed auid=root pid=652 subj=? res=success
> >
> > 	killall -TERM auditd
> > 	type=DAEMON_END msg=audit(2019-04-09 11:51:50.441:5709) : op=terminate auid=root pid=652 subj=? res=success 
> >
> > The USR1 "rotate" and USR2 "resume" log messages need to be fixed in
> > userspace.
> 
> Hmm.  You mention -1 as beeing a problem.  You don't say if auid is a
> concern.

Ok, -1 can be a real value if it isn't actually set, but in this case,
there is information available that isn't being used.

> It looks like all you care about is the sending processes pid.  That
> information is saved in the sending processes siginfo.  As such you may
> be able to remove some of the magic from the code by looking at the
> siginfo of the signal.

We need the sending process' pid, auid and ses, as well as its security
context label and the reason I noticed all this is that soon we'll also
want the audit container identifier as well.

So some of this information is available in siginfo, but I don't know if
all of it is.

> Why it appears the kernel is logging when userspace receives a signal is
> beyond me so I don't know using siginfo makes sense.  I just figure I
> will toss it out there in case it shakes some ideas loose.

That is worth checking to see if it is all available.

Thanks, Eric.

> Eric

- RGB

--
Richard Guy Briggs <rgb at redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635