excluding auditd events

[Mr Dash Four]

> 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)?

> 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? 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).

It was just an idea and is similar to what I have implemented in my 
database-based log system (using PostgreSQL) - a token (via smartcard) 
is taken when the logging starts (at boot up using dracut - I have 
designed a module for this too) and this token is then used to create a 
hash when each log/record is inserted into the system and inserts that 
has as part of the record itself - that prevents tampering with a single 
record, while a separate hash is kept for a single column across the 
entire table (timestamp and transaction id in my case) - that prevents 
tampering entire logs (i.e. adding/deleting entries).

>  But we've 
> 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.

>> 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?
>>     
>
> No idea.
>   
It is a restriction in audit-viewer - at least in the version I am using 
(stock FC13).