AUDIT_SIGNAL_INFO

[Eric Paris]

On Mon, 2009-03-23 at 18:01 +0000, Matthew Booth wrote:
> Eric Paris wrote:
> > On Mon, 2009-03-23 at 15:29 +0000, Matthew Booth wrote:
> >> Under what circumstances will the RHEL 4 kernel generate a message of
> >> type AUDIT_SIGNAL_INFO? My understanding is that it should be sent when
> >> a process sends a signal to the audit daemon, however I have not
> >> observed that. Any ideas?
> > 
> > AUDIT_SIGNAL_INFO is sent when the kernel gets an AUDIT_SIGNAL_INFO
> > request from auditd.
> > 
> > Basically if you send a signal to the audit daemon, the audit daemon
> > sends a message to the kernel requesting AUDIT_SIGNAL_INFO.  The kernel
> > sends the info back to auditd.  Auditd then uses that info to log about
> > the signal it took.  auditd then acts on the signal it took.
> > 
> > So you wouldn't see it in the normal audit logs.  it's really just a
> > communication medium between the kernel and auditd.
> 
> That makes sense. Looking in libaudit.h, I assume you end up with one of
> these:
> 
> /* data structure for who signaled the audit daemon */
> struct audit_sig_info {
>         uid_t           uid;
>         pid_t           pid;
>     char        ctx[0];
> };
> 
> Does this give any information in addition to what you'd get from
> siginfo_t, or is it inherently more reliable?

It's just out of band from the normal audit messages, so auditd can wait
the normal audit queue while it pulls these and figures out how to deal
with them.  If anything it's less reliable, since 2 back to back signals
would actually give you the info about the second signal twice instead
of 2 separate OBJ_PID records.

> Also, is there any way to notice you were sent a KILL or a STOP?

if (sig == SIGTERM || sig == SIGHUP || sig == SIGUSR1 || sig == SIGUSR2)

from AUDIT_SIGNAL_INFO

You could probably get that stuff by watching all kill syscalls and
filtering those based on the OBJ_PID record info I guess.....

-Eric