Further to the discussion I've had with Eric Paris, Steve Grubb and various other members over on the SELinux mailing list, I am now glad I am able to seek help and advice as well as prompt further debate on variety of issues concerning the audit daemon. The main reason for wanting to join the list was that I was having difficulty in trying to exclude certain type of messages (below) for a particular SELinux type being reported to the auditd daemon. In particular, I wanted to exclude the following from being reported: msgtype={USER_ACCT|CRED_ACQ|USER_START|CRED_DISP|USER_END} obj_type=crond_t success=0 When I try to add this as a rule with "auditctl -A exclude,never -F msgtype=USER_ACCT -F obj_type=crond_t -F success=0" I get "Only msgtype field can be used with exclude filter". If left unchecked, I am getting "success" messages on a pretty regular intervals (every time cron daemon runs!), thus filling up my audit logs unnecessarily. This won't normally be a big issue on a small system, but when one has to scan thousands of logs every single hour it becomes a bit of a burden. I won't even go into the issue of filling up disk space and consuming system resources unnecessarily. After having exchanged a few emails with Eric and Steve on that particular issue, it became apparent that since this is a kernel restriction the only feasible solution would be to use "user,exclude" and then the SELinux role I want filtered, though currently no message-type filtering is implemented - either in the kernel, or the audit daemon. I haven't studied the auditd code at all, but to me, this is far too restrictive and if I am to filter on just SELinux context/role/user etc, I am running the risk, however small, of not seeing a security-related messages, which are of potential interest to me as a developer and sysadmin. If I am able to filter on (SELinux) user role and message type (even in userspace) that would be good-enough match! Another couple of things which immediately struck me as soon as I "acquainted" myself with the audit daemon. To me, it is vitally important if any kind of reporting is done on security-related events on a particular system, that reporting to be sufficiently "verifiable" to prevent tampering. Is there such feature implemented in the audit daemon to spot tampering - both on a record level, as well as the audit file as a whole? I couldn't spot such feature during the (admittedly) short time I have studied the audit daemon. Finally, another feature which I am badly missing - the ability to see audit files loaded remotely by the audit-viewer (audit logs located on network shares for example) - this is currently missing and the audit viewer bluntly refuses to load audit file if this file is remotely based and not on the local file system. Is something planned in that respect to enable this?