Re: excluding auditd events
On Thursday, May 26, 2011 09:16:59 AM Mr Dash Four wrote:
> That would be "user,never". The audit daemon does no
filtering. Its in a
> race with the kernel to put events to disk before the kernel's backlog
> overflows.
Yeah, that's it, sorry. Is this backlog configurable (maybe in the same
way tcp/udp buffers are via the sysctl daemon)?
Yes, that is the -b option to auditctl. No matter what you set it to, it can be
overflowed by the right conditions. This is why the audit daemon does no filtering.
> The user filter can filter on: pid, uid, gid, auid, and any part
of the
> subject's selinux label. The only thing not being filtered on that is
> available is the event's record type. There are no other attributes
> available that can be filtered on.
You mean the message type?
An event is composed of records. Sometimes just one record, sometimes 5 or 6. but they
are all linked with a timestamp and serial number.
If so, filtering by selinux label and message type is sufficient, at
least for my
immediate needs.
> It is protected by file permissions. You must be root to write to the
> file. If you want to gpg armor your files when you archive them, its
> possible to script that.
Actually, I was thinking more of having a hash against each record
(horizontally) and, maybe a separate hash over the current tuple of
time:audit count (vertically).
I have been toying with the idea of creating a detached signature where the audit
daemon leaves a public key for use in verifying the integrity of the log. But that
still does not prevent someone from mimicing the algorithm themselves after modifying
the files. For ultimate protection, we suggest remote logging to a box that has
restricted access.
> always taken the position that if someone obtains root
privileges,
> tampering with the logs is the last thing you need to worry about.
I am sure someone said the same thing before SELinux was invented and
implemented in Fedora. In SELinux even if you are root you are still
restricted by the domain you operate in and by the policies in existence
for that particular domain. My view has always been that you can never
be too careful and this adds another level of security - an additional
barrier for "hackers" to have to break, if you like.
In the case where you are running SE Linux correctly - where users are not logging in
as unconfined_t, then you have to be audit admin to do anything with the audit system.
-Steve