AUDIT_SIGNAL_INFO

AUDIT_SIGNAL_INFO

[Matthew Booth]

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?

Thanks,

Matt
-- 
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

Re: AUDIT_SIGNAL_INFO

[Steve Grubb]

On Monday 23 March 2009 11:29:45 Matthew Booth wrote:
> nder what circumstances will the RHEL 4 kernel generate a message of
> type AUDIT_SIGNAL_INFO?

When a SIGTERM is sent to the pid that the kernel has registered for the audit 
daemon.

-Steve

Re: AUDIT_SIGNAL_INFO

[Eric Paris]

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.

-Eric

Re: AUDIT_SIGNAL_INFO

[Matthew Booth]

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?

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

Thanks,

Matt
-- 
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

Re: 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