>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? No, this is not a bug. The audit daemon does the equivalent of "auditctl -e 1" when it starts up. Otherwise the audit system is not active and there won't be any events to receive. >I would imagine that this 'bug' is in the kernel itself, or perhaps a >problem with the cleanliness of auditd's shutdown sequence. Normally, the audit daemon is only shut down when the system is shutting down. >Could/should the above set of permissions to grant Cron the ability to >rotate audit logs be added to default policy? Yes. Cron should be able to send sigusr1 to the audit daemon. >Perhaps controlled by an additional Boolean? That would make it more explicit that its the desired behavior, so it sounds good to me. >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. That might be an even bigger permission grant. By allowing cron to run auditctl, it now has the ability to do "auditctl -D" or "-e 0" thereby deactivating the audit system. >Would it perhaps be better to relabel /etc/cron.daily/0auditrotate as >auditctl_exec_t? Still a big permission grant. >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. It depends on how busy your system is regarding audit traffic. If you have a busy system, you'll need to increase the backlog. This is only because the audit damon is busy rotating logs and the queue in the kernel is accumulating events. It should be noted that the audit system only cares about files that fit its naming scheme. renaming the logs will cause the audit system to not look at the files during rotation, but then ausearch/aureport won't automatically know the logs either. >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. That might make it invisible. But gzipping the files will mean that ausearch/aureport will no longer work and you'll have to unzip the files just to use them. >Could/should logwatch_t be granted permission to be an audit_log reader >under latest policy by default, please? I'd be leary of granting this. >Perhaps controlled by an additional Boolean? That might make it slightly better, but I really don't like audit/logwatch integration. What are you actually looking for out of logwatch? >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. See...not so good. If I knew what you were after, I could probably show you a better way to do it. >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. Have you ever tried aureport? BTW, I put a new FC4 srpm on my people page, but I don't forsee ever building and releasing it through the Fedora Channel since FC4 is no longer in support. You can build it and use it theough. The file is here: http://people.redhat.com/sgrubb/audit/audit-1.0.15-1.fc4.src.rpm I recommend updating to it for anyone that seriously wants auditing on FC4. That version includes a backported version of the realtime interface. -Steve ____________________________________________________________________________________ The all-new Yahoo! Mail beta Fire up a more powerful email and get things done faster. http://new.mail.yahoo.com -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
