Bug 1673487

I am not sure if adding such dependency would be intentional - do we really need - by installing an _auditing_ tool - to install nfs-utils, iscsi-initiator-utils, fcoe-utils, device-mapper-multipath, .. even if dont need their functionality / dont need to monitor anything related to it?

I think the audit rules should be either fine-tuned per currently present FS or storage capabilities (i.e. dont put nfs audit rules if nfs-utils isnt installed), or augenrules should have an option to ignore/skip rules it fail to process.

Dave, as you came up with the rules, any idea here?

FYI typical list of missing files referred by the audit rules:

/usr/sbin/xfs_scrub
/usr/sbin/xfs_scrub_all
/etc/e2fsck.conf
/sbin/mount.nfs
/sbin/mount.nfs4
/sbin/umount.nfs
/sbin/umount.nfs4
/usr/sbin/exportfs
/usr/sbin/nfsconf
/usr/sbin/rpcdebug
/etc/gssproxy/24-nfs-server.conf
/etc/modprobe.d/lockd.conf
/etc/nfs.conf
/etc/nfsmount.conf
/etc/request-key.d/id_resolver.conf
/usr/bin/cifscreds
/usr/bin/setcifsacl
/usr/sbin/mount.cifs
/etc/request-key.d/cifs.idmap.conf
/etc/request-key.d/cifs.spnego.conf
/usr/sbin/lvmconf
/usr/sbin/mpathconf
/usr/sbin/mpathpersist
/usr/sbin/multipath
/usr/share/doc/device-mapper-multipath/multipath.conf
/usr/sbin/fcnsq
/usr/sbin/fcoeadm
/usr/sbin/iscsiadm
/etc/iscsi/iscsid.conf
/usr/lib/tmpfiles.d/iscsi.conf


that are provided by these packages:

cifs-utils
device-mapper-multipath
fcoe-utils
iscsi-initiator-utils
nfs-utils

(In reply to Pavel Moravec from comment #1)
> I am not sure if adding such dependency would be intentional - do we really
> need - by installing an _auditing_ tool - to install nfs-utils,
> iscsi-initiator-utils, fcoe-utils, device-mapper-multipath, .. even if dont
> need their functionality / dont need to monitor anything related to it?
> 
I agree installing things like fcoe-utils just because you installed sos-audit probably would not be a good idea.  You would have the same problem if you removed one of the RPMs at a later time.  The first release of sos-audit has a shortfall of any RPM install or uninstall won't update the rules so again customization is needed. We made a design decision not to include any rules files in the individual packages but keep them in sos-audit.  That said maybe it was a bad idea to not have a consistent set of rules based on installed RPMs.

> I think the audit rules should be either fine-tuned per currently present FS
> or storage capabilities (i.e. dont put nfs audit rules if nfs-utils isnt
> installed), or augenrules should have an option to ignore/skip rules it fail
> to process.
> 
> Dave, as you came up with the rules, any idea here?

My gut feel is try the first idea - customize based on the currently installed RPMs.  BTW, 'auditctl' does have a '-c' option but that I don't think is too great.

The first implementation was very simple and was an attempt at making a comprehensive set of rules that someone may want to customize based on the problem at hand.  So ideally one would:
1. Install sos-audit
2. Customize the rules for their situation (i.e. edit files in /usr/lib/sos/audit/rules.d)
3. Run augenrules --load

As a simpleton idea, print a message for the user to examine the rules and customize for their situation before this install line:
"NOTE: Audit rules changed in /etc/audit/rules.d. Run 'augenrules --load' to activate the new rules."

But maybe we need something to attempt #2 above as a "first pass" to make a consistent set of rules even if it would not apply to all situations.  For example, one might only be interested in auditing xfs commands in one instance, and in another instance may be interested in auditing all filesystem commands / changes, and there's no way to know the user's needs / intent.  If we had an attempt at #2 though, then we could run that at install time to customize it by default based on what is installed.

Some ideas on #2 a customization that reflects the set of RPMs installed and guesses intent.  
A. Rather than 'filesystem' and 'storage' rules files, make a separate rules file inside /usr/lib/sos/audit/rules.d for each package, then enable/disable based on what is there at install time.
B. A script to make a pass through the /usr/lib/sos/audit/rules.d files based on the installed RPM names, and then comment out rules pertaining to RPMs that are not installed.
* NOTE: The RPM name is usually at the end but I see now apparently there is missing '-k' value for rules like the .conf files for some reason - there may be a bug in the generator script there.
C. Include some generator scripts at install time and generate the rules files based on what is installed, rather than a static version in the RPM.  Then you'd have the generator scripts there and could run them again when the set of RPMs changes.

What about:
1) not providing static content of 40-sos-*.rules but generate them in package preinstall script via sos-audit-*-rules-generator.sh scripts
2) the script will generate just rules "applicable" to the given system - in particular the "for p in $RPMS" loops will start with command like:

rpm --quiet -q $p || continue

such that if e.g. nfs-utils package isn't installed, its rules wont be generated & deployed ?


If one newly installs e.g. nfs-utils and would like to have audit rules for it as well, reinstalling sos-audit will help.

Well, it won't, since "augenrules --load" will try to load rules it already has (is there an option to forget/drop loaded rules? or forcefully reload all?).

Anyway, this augenrules limitation is out of scope sos-audit - the above approach should ensure proper rules are present (shall we run "augenrules --load" in post-install and post-uninstall scripts? or leave it on user?).


Is this idea sound?

IMO, if you can make a dynamic set of rules at install time based on what is installed that might be better and save this user-visible issue.  Just guessing but probably a system will have a stable set of packages by the time sos-audit is installed so it may be overall a win.

FWIW, I wrote up a FAQ Q2 that at least partially covers this issue for now:
https://access.redhat.com/articles/3599171#q2-why-does-sos-audit-include-rules-for-tools-and-configuration-files-that-are-not-installed-6

As an alternative to 'augenrules --load' users can use:
# auditctl -D
# auditctl -R /etc/audit/audit.rules

I can modify the above article depending on what we decide for this bug.

(In reply to Dave Wysochanski from comment #7)
> IMO, if you can make a dynamic set of rules at install time based on what is
> installed that might be better and save this user-visible issue.  Just
> guessing but probably a system will have a stable set of packages by the
> time sos-audit is installed so it may be overall a win.
> 
> FWIW, I wrote up a FAQ Q2 that at least partially covers this issue for now:
> https://access.redhat.com/articles/3599171#q2-why-does-sos-audit-include-
> rules-for-tools-and-configuration-files-that-are-not-installed-6
> 
> As an alternative to 'augenrules --load' users can use:
> # auditctl -D
> # auditctl -R /etc/audit/audit.rules
> 
> I can modify the above article depending on what we decide for this bug.

Could somebody prepare such a list of dynamic rules?

I am not domain expert on auditctl / what installed package should load what rule..

(and defering to 8.2)

(In reply to Pavel Moravec from comment #8)
> 
> Could somebody prepare such a list of dynamic rules?
> 

One possibly simple approach / starting point might be to add another filter check for installed package into the generator scripts, and run them at install time:

https://github.com/sosreport/sos-audit/blob/46a80f0a342f4d5cba91d6c28a8e81e7f1b11356/contrib/sos-audit-filesystem-rules-generator.sh

RPMS="xfsprogs e2fsprogs nfs-utils cifs-utils"
echo "## $RULES_FILE: Filesystem related audit rules that change system state." >> $RULES_FILE
echo "## The audit rules monitor both executable as well as configuration file modification." >> $RULES_FILE
echo "## The executable and configuration files are from the following RPMs: $RPMS " >> $RULES_FILE
for p in $RPMS
do
	echo "# $p" >> $RULES_FILE
	dnf repoquery --arch x86_64 -l $p > /tmp/$p-repoquery.txt
	for f in $(cat /tmp/$p-repoquery.txt | grep bin | sort | uniq); do
		if [[ ${binary_filter[$p,$f]} ]]; then
			echo "skipping $p $f"
			continue
		fi
+                # Dynamic rules check; don't add rule if RPM is not installed
+                rpm -q $p > /dev/null 2>&1
+                if [ $? -eq 1 ]; then
+			continue
+		fi
		echo "-w $f -p x -k filesystem_changes -k $p" >> $RULES_FILE
	done
	for f in $(cat /tmp/$p-repoquery.txt | grep \\.conf$ | sort | uniq); do
		echo "-w $f -p wa -k filesystem_changes -k $p" >> $RULES_FILE
	done
done

no time to fix it in 8.3, deferring to later release

Should augenrules --load be made clever enough to handle this?

- The files that it combines could have dependencies tagged within them or deduced from the contents (eg package X must be installed or file Y must exist) and if those dependencies aren't satisfied the whole file is skipped (with a warning).

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days