Re: excluding auditd events
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)?