Bug 1746018

*** Bug 1746023 has been marked as a duplicate of this bug. ***

This is fixed with upstream commit f805a2e.

audit-3.0-0.14.20191104git1c2f876 has been built to address this issue.

I need to clarify one thing.

Original 30-ospp-v42.rules consisted of several parts in the following order:

 * first, load 10-base-config.rules, 11-loginuid.rules, and 43-module-load.rules
 * successful/Unsuccessful file creation (open with O_CREAT)
 * successful/Unsuccessful file modifications (open for write or truncate)
 * successful/Unsuccessful file access (any other opens) This has to go last.
 * successful/Unsuccessful file delete
 * successful/Unsuccessful permission change
 * successful/Unsuccessful ownership change
 * user add delete modify
 * user enable and disable (handled by pam)
 * group add delete modify
 * sse of special rights for config changes.
 * privilege escalation via su or sudo (handled by pam)
 * audit log access
 * attempts to Alter Process and Session Initiation Information
 * attempts to modify MAC controls
 * software updates (handled by rpm)
 * system start and shutdown (handled by systemd)
 * kernel Module loading (handled by 43-module-load.rules)

Now, after split it is as follows:
 
 a) 10-base-config.rules, 11-loginuid.rules, and 43-module-load.rules are still separated
 b) successful/Unsuccessful file creation (open with O_CREAT)
    - in 30-ospp-v42-1-create-failed.rules and 30-ospp-v42-1-create-success.rules
 c) successful/Unsuccessful file modifications (open for write or truncate)
    - in 30-ospp-v42-2-modify-failed.rules and 30-ospp-v42-2-modify-success.rules
 d) successful/Unsuccessful file access (any other opens) This has to go last.
    - in 30-ospp-v42-3-access-failed.rules and 30-ospp-v42-3-access-success.rules
 e) successful/Unsuccessful file delete
    - in 30-ospp-v42-4-delete-failed.rules and 30-ospp-v42-4-delete-success.rules
 f) successful/Unsuccessful permission change
    - in 30-ospp-v42-5-perm-change-failed.rules and 30-ospp-v42-5-perm-change-success.rules
 g) successful/Unsuccessful ownership change
    - in 30-ospp-v42-6-owner-change-failed.rules and 30-ospp-v42-6-owner-change-success.rules
 h) user add delete modify
    - in 30-ospp-v42.rules
 i) user enable and disable (handled by pam)
 j) group add delete modify
    - 30-ospp-v42.rules
 k) use of special rights for config changes.
    - 30-ospp-v42.rules
 l) privilege escalation via su or sudo (handled by pam)
 m) audit log access
    - 30-ospp-v42.rules
 n) attempts to Alter Process and Session Initiation Information
 o) attempts to modify MAC controls
    - 30-ospp-v42.rules
 p) software updates (handled by rpm)
 r) system start and shutdown (handled by systemd)
 s) kernel Module loading (handled by 43-module-load.rules)

Augenrules sorts rules files in natual order (ls -1v) and hence it loads rules in the following order:

 1.   10-base-config.rules
 2.   11-loginuid.rules
 3.   30-ospp-v42.rules
 4-9. 30-ospp-v42-[123456].rules
 10.  43-module-load.rules

Resulting rules list is different from RHEL-8.1 because section (h-o) was in the beginning previous and now it is in the end. Is that intentional? I aware of the fact that ordering is important only between specific parts and the rest can be combined arbitrarily but I want to double-check this.

This is known and expected. The rules that need coordinating order are within one file. So, these can be mixes and matched. The rules in 30-ospp-v42.rules were at the bottom in the original file anyways. So, they are still roughly in the same place.

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, 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/RHBA-2020:1812