excluding auditd events

[Steve Grubb]

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