Description of problem:

Some customers noticed that the changes applied on a system either through using "oscap xccdf remediate" command of through using Anaconda's addon "org_fedora_oscap" are difficult to track: in particular files that are not part of packages (e.g. /etc/audit/rules.d/*.conf).

Additionally, upon upgrading a system between minor releases (e.g. 8.1 -> 8.3), it appears that the system gets a different configuration than a freshly installed one.
For example, a 8.1 system (and upgraded one to 8.3) gets this:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

1. ls -l /etc/audit/rules.d/
   total 32
   rw-rr-. 1 root root 244 Feb 2 14:21 10-base-config.rules
   rw-rr-. 1 root root 93 Feb 2 14:21 11-loginuid.rules
   rw-rr-. 1 root root 13171 Feb 2 14:21 30-ospp-v42.rules
   rw-rr-. 1 root root 398 Feb 2 14:21 43-module-load.rules
   rw------. 1 root root 244 Feb 2 14:18 audit.rules
   • • • • • • • 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Whereas a freshly installed 8.3 system gets this:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

1. ls -l /etc/audit/rules.d/
   rw-rr-. 1 root root 243 Feb 2 14:27 10-base-config.rules
   rw-rr-. 1 root root 92 Feb 2 14:27 11-loginuid.rules
   rw-rr-. 1 root root 1500 Feb 2 14:27 30-ospp-v42-1-create-failed.rules
   rw-rr-. 1 root root 746 Feb 2 14:27 30-ospp-v42-1-create-success.rules
   rw-rr-. 1 root root 1646 Feb 2 14:27 30-ospp-v42-2-modify-failed.rules
   rw-rr-. 1 root root 826 Feb 2 14:27 30-ospp-v42-2-modify-success.rules
   rw-rr-. 1 root root 593 Feb 2 14:27 30-ospp-v42-3-access-failed.rules
   rw-rr-. 1 root root 383 Feb 2 14:27 30-ospp-v42-3-access-success.rules
   rw-rr-. 1 root root 562 Feb 2 14:27 30-ospp-v42-4-delete-failed.rules
   rw-rr-. 1 root root 284 Feb 2 14:27 30-ospp-v42-4-delete-success.rules
   rw-rr-. 1 root root 816 Feb 2 14:27 30-ospp-v42-5-perm-change-failed.rules
   rw-rr-. 1 root root 414 Feb 2 14:27 30-ospp-v42-5-perm-change-success.rules
   rw-rr-. 1 root root 579 Feb 2 14:27 30-ospp-v42-6-owner-change-failed.rules
   rw-rr-. 1 root root 295 Feb 2 14:27 30-ospp-v42-6-owner-change-success.rules
   rw-rr-. 1 root root 5291 Feb 2 14:27 30-ospp-v42.rules
   rw-rr-. 1 root root 398 Feb 2 14:27 43-module-load.rules
   rw------. 1 root root 244 Feb 2 14:24 audit.rules
   • • • • • • • 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Currently there is no way for an admin to re-apply a policy to get to latest level, this is problematic.
I see multiple ways to improve the situation:

1. Modified files and new files should have a header stating who did the modification

something like this:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

1. Block applied by oscap xccdf remediate --rule <...>
   [...]
2. End of Block
   • • • • • • • 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

e.g. for /etc/bashrc containing "tmux" block, this should be clearly stated (taken from a 8.3 fresh system):
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
if [ "$PS1" ]; then
parent=$(ps -o ppid= -p $$)
name=$(ps -o comm= -p $parent)
case "$name" in sshd|login) exec tmux ;; esac
fi
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

2. A "oscap remediation" log should be stored somewhere listing all the new and modified files, with history so that the admin can follow changes between "oscap remediate" runs

3. Ideally there should be some way to undo the changes, but I understand this could be hard to do

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

All versions

How reproducible:

N/A