Bug 1777239 - Unable to exclude files from auditing
Summary: Unable to exclude files from auditing
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel
Version: 7.7
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: 7.7
Assignee: Richard Guy Briggs
QA Contact: Ondrej Moriš
Depends On:
Blocks: 1782781 1798512 1806429 1806430
TreeView+ depends on / blocked
Reported: 2019-11-27 09:14 UTC by Ravindra Patil
Modified: 2021-08-27 22:34 UTC (History)
13 users (show)

Fixed In Version: kernel-3.10.0-1127.2.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1798512 1806429 1806430 (view as bug list)
Last Closed: 2020-09-29 21:03:35 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:4060 0 None None None 2020-09-29 21:05:24 UTC

Description Ravindra Patil 2019-11-27 09:14:14 UTC
Description of problem:

Trying to exclude folder or files from auditing does not work. 

I have configured audit to audit all commands 
-a exit,always -F arch=b32 -S execve -k auditcmd
-a exit,always -F arch=b64 -S execve -k auditcmd

But, I want exclude audit logs generated for particular directory /apps/test, so added following exclude rule as first rule 

-a exit,never -F dir=/apps/test/

But audit logs are still collected for this directory

Version-Release number of selected component (if applicable):

How reproducible:
- Add rules for auditing
- Add rule to exclude directory

Steps to Reproduce:
1. Configure to audit
2. Exclude directory 

Actual results:
Audit logs are collected for excluded directory. 

Expected results:
Audit logs should not be collected. 

Additional info:

We have KCS https://access.redhat.com/solutions/416863 but customer have reported that it does not work.

Comment 3 Steve Grubb 2019-12-06 19:16:20 UTC
[root@ospp ~]# cp /usr/bin/ls /opt/
[root@ospp ~]# ls -l /opt/
total 116
-rwxr-xr-x. 1 root root 117680 Dec  6 14:11 ls
[root@ospp ~]# auditctl -D
No rules
[root@ospp ~]# auditctl -a exit,never -F dir=/opt
[root@ospp ~]# auditctl -a exit,always -F arch=b64 -S execve -k auditcmd
[root@ospp ~]# ls
anaconda-ks.cfg  original-ks.cfg
[root@ospp ~]# /opt/ls
anaconda-ks.cfg  original-ks.cfg
[root@ospp ~]# auditctl -D
No rules
[root@ospp ~]# ausearch --start 14:10 -k auditcmd --raw | aureport --summary -x

Executable Summary Report
total  file
2  /usr/sbin/auditctl
1  /usr/bin/ls
[root@ospp ~]# uname -r

Seems to be working as expected.

Comment 5 Steve Grubb 2019-12-09 14:50:43 UTC
The -D is to make sure that we are starting from a known state and that nothing is interfering. The audit system is a first matching rule wins system. So, we want to limit the rules to what's needed to verify if its working or not. net-snmp has nothing to do with whether the audit system is working.

Can we close this bz?

Comment 17 Steve Grubb 2019-12-28 22:33:41 UTC
So far, all the discussion on ths bz is that there is a claim that never rules are not working. As evidence, what is provided is snippets of EXECVE records. The never rule does not match against anything in EXECVE. It matches against things that have a PATH record. If there is no PATH record, then there was no path resolution that resulted in an exact device and inode. The kernel only knows numbers. It does not know strings.

I need to see full events that are problematic. Not the output of grep. You get full events with ausearch -i

Comment 20 Steve Grubb 2019-12-31 20:45:01 UTC
Based on looking at the events in question, what we have is a rule that is watching pgstat.stat. Something is perturbing the file system which is changing the inode. This particular event is being generated by:

/* Update inode info in audit rules based on filesystem event. */
static void audit_update_watch(struct audit_parent *parent,
                               const struct qstr *dname, dev_t dev,
                               unsigned long ino, unsigned invalidating)

in kernel/audit_watch.c. This particular event is meant to be informative to say that there was a change that caused the underlying rule configuration to change. And to maintain the watch, the rule was modified. This is all invisible to people operating the system. It is just bookkeeping.

The never rule is intended to match system activity that the user is doing, such as executing a program. It is not intended to match bookkeeping activity. Now, it is debatable as to whether this bookkeeping information is actually needed.

Common Criteria calls out for any action that modifies the audit trail to be recorded. That usually is interpreted to mean insertion or removal of rules. I have a feeling that someone thought that modifying the inode information was also required. But since no device/inode info is logged at insertion and no device/inode information is logged on update, there is nothing meaningful being communicated to the admin. One can assume that the rule was not "modified" because it is still watching the intended target. If the device or inode cannot be resolved, the rule is dropped and that would be logged.

I think the correct resolution is to drop logging config_update events since the watch is still in effect but just on another unknown inode. This bz will be transferred to the kernel for further investigation.

As a workaround I would say that you can use the exclude filter to get rid of ALL config_change events. Unfortunately, there's not much on the config_change event to match on to be more selective. (The kernel does not do string matches.) This rule should get rid of all of the config_change events:

-a always,exclude -F msgtype=CONFIG_CHANGE

Comment 21 Steve Grubb 2019-12-31 20:55:38 UTC
A patch like this should get rid of the offending lines:

diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index 787c7afdf829..f345ef95750a 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -317,8 +317,6 @@ static void audit_update_watch(struct audit_parent *parent,
                        if (oentry->rule.exe)
-                       audit_watch_log_rule_change(r, owatch, "updated_rules");
                        call_rcu(&oentry->rcu, audit_free_rule_rcu);

Someone who knows systemtap could probably fix this as a temporary workaround assuming this is acceptable upstream.

Comment 22 Steve Grubb 2020-01-05 15:25:42 UTC
Patch was sent upstream for discussion:

Comment 31 Jan Stancek 2020-02-22 22:37:34 UTC
Patch(es) committed on kernel-3.10.0-1127.2.el7

Comment 43 errata-xmlrpc 2020-09-29 21:03:35 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: kernel security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.