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?
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
