audit.rules being really processed sequentially?

[Ede Wolf]

Thanks very much for your help and heads up, even though of course bad news.

Ede

Am 02.09.21 um 18:21 schrieb Steve Grubb:
> 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
> 
>