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 <[email protected]> writes: > > On 2019-04-09 17:37, Steve Grubb wrote: > >> On Tue, 9 Apr 2019 10:02:59 -0400 > >> Richard Guy Briggs <[email protected]> wrote: > >> > >> > On 2019-04-09 08:01, Steve Grubb wrote: > >> > > On Mon, 8 Apr 2019 23:52:29 -0400 Richard Guy Briggs > >> > > <[email protected]> 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 <[email protected]> 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 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
