audit.rules being really processed sequentially?

Steve Grubb sgrubb at redhat.com
Thu Sep 2 16:21:27 UTC 2021


On Thursday, September 2, 2021 11:54:12 AM EDT Ede Wolf wrote:
> In my pursuit of taming auditd in that it only logs what has explicitly
> been defined and nothing more, I've thought of a set of catch all rules
> at the end. As the rules file is supposedly being processed
> sequentially, i.e. first hit matches, this ought to work. But it doesn't.
> 
> Having a very simple rules file as an example:
> 
> -D
> -e 1
> 
> -a exit,always -F arch=b64 -S execve -F path=/bin/vi -k EDIT_FILE
> 
> -a always,exclude -F msgtype=EXECVE
> -a always,exclude -F msgtype=FD_PAIR
> -a always,exclude -F msgtype=FS_RELABEL
> ...
> 
> (continue this for every messagetype from this link:
> 
>   https://access.redhat.com/articles/4409591#audit-record-types-2)
> 
> As easily to be guessed, my expectation would be, the invokation of vi
> by anyone would get logged, as that rules comes first, but really
> nothing else, as it is being discaded by the catchall rules.
> 
> Surprisingly however, in reality, nothing gets logged at all, not even
> the invocation of vi.
> 
> Now, removing those catchall rules at the end does log the calling of
> vi, but of course also all other stuff I neither  have defined nor want
> to be written out.
> 
> So, if the audit.rules file really is being processed sequentally, what
> am I missing in my approach?

It might be useful to look at slide 15 of this:

http://people.redhat.com/sgrubb/audit/audit_ids_2011.pdf

The output of the rule matching engine gets fed to the exclude filter for a 
second look. The exclude filter then drops objectionable records. In your 
case, it its told to drop everything.

Audit records in the 1300 block are related to rules. You need to let all of 
them through.

-Steve





More information about the Linux-audit mailing list