Bug 1777239

[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
3.10.0-957.el7.x86_64

Seems to be working as expected.

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?

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

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

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_remove_mark(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.

Patch was sent upstream for discussion:
https://www.redhat.com/archives/linux-audit/2020-January/msg00003.html

Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=26392522
Patchwork: http://patchwork.usersys.redhat.com/patch/294784/

Patch(es) committed on kernel-3.10.0-1127.2.el7

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.

https://access.redhat.com/errata/RHSA-2020:4060