AUDIT_SIGNAL_INFO
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
Signature · 6 lines
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
Quoted 2 lines · 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
Quoted 4 lines · 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?
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
Quoted 9 lines · Eric Paris
Quoted 4 lines · 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?
AUDIT_SIGNAL_INFOis sent when the kernel gets anAUDIT_SIGNAL_INFOrequest from auditd.
Quoted 7 lines
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
Signature · 6 lines
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
Quoted 22 lines · Matthew Booth
Quoted 9 lines · Eric Paris
Quoted 4 lines · 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?
AUDIT_SIGNAL_INFOis sent when the kernel gets anAUDIT_SIGNAL_INFOrequest from auditd.Quoted 7 lines
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 */
Quoted 8 lines
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.
Quoted 1 line
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