Audit Daemon / LogWatch / SELinux et al

[Ted Rule]

I wanted to integrate auditd with Logwatch as well as providing for
overnight audit log rotation. Sadly, I'm still on FC4, so some of what
follows may be out of date. Nevertheless, since the current FC6 Logwatch
RPM isn't able to process /var/log/audit/audit.log, I thought the
following might be of general interest, anyway.

By default, my system was previously set with auditd disabled on boot.

Once I enabled auditd, I found that auditd logged numerous types of
message other than plain SELinux AVC's. Syslog, ( actually syslog-ng
reading /proc/kmsg ), had only logged AVC's. Curiously, if I started
auditd, and then stopped it again without a reboot, syslog immediately
started logging all manner of non-AVC messages.

Is it a bug that only AVC messages are logged via syslog when auditd is
never started, OR is it a bug that non-AVC messages are logged via
syslog when auditd is stopped after being run temporarily?

I would imagine that this 'bug' is in the kernel itself, or perhaps a
problem with the cleanliness of auditd's shutdown sequence.



The audit RPM provides an example Cron script for SIGUSR1'ing auditd
on demand. I created a copy of this in /etc/cron.daily so that it is
called BEFORE logwatch is run overnight, as in:

$ rpm -qvl audit |grep cron
-rw-r--r--  1 root root    271 Nov  4  2005
                     /usr/share/doc/audit-1.0.14/auditd.cron

$ cat /etc/cron.daily/0auditrotate
#!/bin/sh

##########
# This script can be installed to get a daily log rotation
# based on a cron job.
##########

/sbin/service auditd rotate
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
    /usr/bin/logger -t auditd "ALERT exited abnormally with
[$EXITVALUE]"
fi
exit 0
$

The problem I then found was that system_crond_t had insufficient
permissions to signal the daemon, so I had to add these extra
permissions to my local SELinux policy:

# Allow Cron invocations of auditdrotate to kill -USR1 auditd
# Cron needs to read /var/run/audit.pid, and /proc/<pid of auditd>
# as well as SIGUSR1 the process itself.
allow system_crond_t auditd_var_run_t:file r_file_perms;
allow system_crond_t auditd_t:dir r_dir_perms;
allow system_crond_t auditd_t:process { signull signal };

Could/should the above set of permissions to grant Cron the ability to
rotate audit logs be added to default policy? Perhaps controlled by an
additional Boolean?

Would it be a better overall solution to add an extra command-line
option to auditctl so that it signals auditd via either SIGUSR1 or a
private control channel? Cron could then be granted permission to run
auditctl instead of directly signalling the daemon.

Would it perhaps be better to relabel /etc/cron.daily/0auditrotate as
auditctl_exec_t?



I note from auditd.conf's man page that raising the number of logs which
auditd rotates upon receipt of SIGUSR1 may be problematical as it may
require increasing the kernel backlog setting in audit.rules. Since I
would prefer to be able to have a complete rolling month's worth of
history to hand, with or without compression, I wonder if it might be
useful to get /etc/cron.daily/0auditrotate to pre-rotate AND gzip older
logs before SIGUSR1'ing auditd. Since the gzip'ed logs would presumably
be "invisible" to auditd, but "visible" to  Logwatch's Archive
processing, this would still allow Logwatch to run correctly, whilst
reducing the rotation processing load on auditd itself. There are
probably numerous little race conditions to beware of here, of course!



The next problem, of course, was that logwatch, running as
system_crond_t under FC4, but presumably as logwatch_t under FC5 and
above, is unable to read /var/log/audit by default.

To work round this, I duly added this set of permissions to my local
policy:

# Allow Cron invocations of logwatch to read /var/log/audit
allow system_crond_t auditd_log_t:file r_file_perms;
allow system_crond_t auditd_log_t:dir r_dir_perms;

Could/should logwatch_t be granted permission to be an audit_log reader
under latest policy by default, please? Perhaps controlled by an
additional Boolean?



The default installation of logwatch itself has a script for processing
the AVC messages which are routed via syslog, namely
/usr/share/logwatch/scripts/services/audit.
Unfortunately, because of the difference in log format, and the log
timestamping in particular, logwatch is unable to
process /var/log/audit/audit.log "out of the box".
Furthermore, it seems that this script is not capable of properly
handling various non-AVC messages.


To work round this problem, I created an extra shared script for
logwatch, /etc/logwatch/scripts/shared/applyauditdate, which explicitly
matched on the "date +%s" style timestamp in audit messages. This was
tied into some additional configuration files, and a modified form
of /usr/share/logwatch/scripts/services/audit, which I haved placed
in /etc/logwatch/scripts/services/auditd, for processing raw audit
daemon logs. I would envisage that a fully integrated installation would
place the new script in /usr/share/logwatch/scripts/services/auditd, of
course.

With this all in place, I was finally able to get a daily Logwatch
summary of all audit daemon activity, including all the non-AVC
messages, albeit currently limited to a 4-day history.



-- 
Ted Rule

Director, Layer3 Systems Ltd

W: http://www.layer3.co.uk/