excluding auditd events

Mr Dash Four mr.dash.four at googlemail.com
Thu May 26 14:07:57 UTC 2011


> 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.
>   
Thanks, I realise it doesn't bring 100% certainty against overflowing 
(what does?), but it at least helps.

>> 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.
>   
So filtering could be done on message type and SElinux subject, 
eventually, by using "user,never"? I take it, this isn't implemented yet 
(the message type filter part)?

> 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.
That kind of tampering won't be possible if the token is taken from a 
trusted source (smartcard in my case), is then kept in-memory and is 
never visible to anyone/anything except the audit daemon. That token is 
then used to create all the hashes needed to do the verification. When 
sysadmin (or other authorised personnel) need to do record verification 
they simply insert the smartcard, run a separate tool 
(ausearch/aureport-type tool), which retrieves the token again from the 
smartcard and then verifies whatever needs to be verified in the logs 
and produces the report needed.

At least this is how I have it currently implemented in my database.

>  For ultimate protection, we suggest remote logging to a box that has 
> restricted access.
>   
That is certainly a possibility (but then again the box needs to be 
"secure"), though since I am not very familiar with the audit daemon 
I'll just ask - is the connection between the 2 daemons (on the secure 
box as well as the daemon sending the logs) encrypted so to prevent 
tampering in-route (man in the middle etc attacks)?




More information about the Linux-audit mailing list