Hello,

Do anyone knows the solution to log the Kill of the audispd before actually audispd dies.

My system is audited only using audispd, so... this is the weakpoint.

Until now, I use -a exit,always -F arch=b64 -S kill but audispd is able to follow-up the event.

Regards.

Asserting a default O.S. setup the "main" service will be auditd. Auditd logs to /var/log/audit/audit.log. (If /proc/cmdline contains "audit=1" and auditd is not installed then AVC messages get logged to /var/log/messages.) Audisp is a real-time interface to audit events. It "just" multiplexes what auditd sees. It is not a standalone service but it is started by auditd. By default the only audisp plugin enabled is the af_unix one which dispatches through the /var/run/audispd_events socket. By default the only user of that socket is Setroubleshootd. So in essence it is not correct to say the system "is audited only using audispd": auditd is first and a "kill" rule in /etc/audit/audit.rules should still be logged in /var/log/audit/audit.log as auditd registers the kill. (It just can not be dispatched through audisp as it's killed.)

So I don't know what you mean to say with "audispd is able to follow-up the event". Are you saying your "-a exit,always -F arch=b64 -S" does not register kills in /var/log/audit/audit.log?

Yes./var/log/audit.log is correctly fed. You're right.

The problem for me is to log locally is no value for me. I try to be PCI compliant. To achieve that, all information performed by root have to be externalized ASAP, so instantly.

That's what I gave a try to audispd. But it's impossible to respawn both auditd and audispd independently in inittab. Audispd restarted alone does not work anymore.

So I tried to use a system like syslog/syslog-ng to transport outside audit information almost instantly. I've tried syslog-ng to source the audit.log file. The problem is when audit.log rotation occurs, syslog-ng looses the inode and does not anymore follow-up the records.

I've tried to replace audit.log by a FIFO named audit.log. But auditd seems not to like it and does not start.

Any idea ?

Next time please try to be complete in your original post (OP) when presenting your problem.


Did it ever? That would be absolutely wrong for the reasons I gave...


Syslog implementations respond to signals like "HUP" with reopening log files. Check if Syslog-NG does that too. Auditd responds to SIGUSR1 and SIGUSR2 for rotating logs and resuming logging. So with those you have full control over when you want to rotate logs (if you configure audit properly) if you're thinking of replacing default rotate behaviour with a cronjob in which you can govern both Syslog-NG and Auditd. (To avoid missing logs during rotation raise the kernel backlog buffers ("-b") in /etc/audit/audit.rules from 64 1K buffers to the maximum of 99.) Did you look into audisp remote logging directly using the "audisp-remote" plugin? BTW how much logs do you keep? And what's their file sizes?

Back to check killing of audisp, given the default af_unix plugin using the /var/run/audispd_events socket, you could poll it (something like '/sbin/fuser /var/run/audispd_events') for usage and respond to that?

Sorry for the PCI miss. But I think a local-only log for super-user activity has almost no value in any security context.

Regarding audispd : What I wanted to tell is I've tried restarted audisp after a kill on it and syslogd did not report anymore.

I've checked syslog-ng. It seems to be ok in the version I've tried this morning.

I've got a glance on audisp-remote this morning. But because it's handled by audispd. I though I will have the same miss than using syslog plugin (in a kill on audispd event). So I've given up that way. I've set up syslog-ng to follow /var/log/audit.log and also std syslog facilities in the case auditd will be killed and kauditd will so log in the syslog. This way, I can be warn of a problem on the machine remotely.
I've also set syslog-ng in respawn mode.

I do not log a lot of information in the current configuration, only interactive user that can become root. But the machine on which I need to audit are XEN hypervisors when there's near 0 interactive login. But I however need a rotation to be sure the filesystem will never be filled by the system. Maybe in the future, I also will need to monitor more syscalls.

Thank you for your help.

Oh, last thing...

One event I miss with this behaviour is I miss the Kill event initiated by root. When auditd is killed, the kernel start to log but has no "knowledge" of the past kill event. So when we read the log, we can know that the auditd has disappeared but we don't know if it was killed or it dies by itself.