From: Mr Dash Four <mr.dash.four@googlemail.com>
To: Linux-audit <linux-audit@redhat.com>
Subject: excluding auditd events
Date: Thu, 26 May 2011 01:22:22 +0100 [thread overview]
Message-ID: <4DDD9D3E.8020001@googlemail.com> (raw)
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?
next reply other threads:[~2011-05-26 0:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-26 0:22 Mr Dash Four [this message]
[not found] ` <201105260802.21606.sgrubb@redhat.com>
2011-05-26 13:16 ` excluding auditd events Mr Dash Four
2011-05-26 13:50 ` Steve Grubb
2011-05-26 14:07 ` Mr Dash Four
2011-05-26 14:16 ` Steve Grubb
2011-05-26 14:23 ` Mr Dash Four
2011-05-26 14:33 ` Steve Grubb
2011-05-26 15:22 ` Mr Dash Four
2011-05-26 15:51 ` LC Bruzenak
2011-05-26 16:10 ` Mr Dash Four
2011-06-01 12:54 ` Mr Dash Four
2011-06-01 14:08 ` LC Bruzenak
2011-06-01 14:47 ` Mr Dash Four
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DDD9D3E.8020001@googlemail.com \
--to=mr.dash.four@googlemail.com \
--cc=linux-audit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox