The auditd rule checks are overly restrictive and check the wrong targets

[trevor-vaughan]

Description of problem:

I discovered the following issues when trying to reuse my audit configuration settings with EL8.

Issue 1: Overly Restrictive Rules

Prior to EL8, users were forced to use the less efficient model of splitting the rules into separate lines per system call.

In EL8, the rules are required to be more efficiently stored on the same line. Unfortunately, this means that settings that could be common between the two platforms are unable to be used.

Additionally, comments should never be part of a rule check because they have absolutely nothing to do with the security of the system.

Issue 2: Incorrect Target Check

The correct target to check is the output of auditctl -l, anything else is subject to issues causing incomplete loads to drop rules.

If checking files, the only file that matters is the /etc/audit/audit.rules file. The random files in rules.d should be used to generate audit.rules but may not necessarily be depending on how the user has configured their system.

Comparison

Inspec both checks the running rules (not random files) and is able to determine that the appropriate system calls are audited regardless of order or collected/split.

Request

As an administrator, I would like to have the scanner reflect the most common methods of setting the parameters so that I can make necessary adjustments to suit my infrastructure. For instance, if fremovexattr were causing issues for some reason, then I would get failures where 95% of my checks are correct.

SCAP Security Guide Version:

• f80d794

Operating System Version:

RHEL and CentOS

Steps to Reproduce:

1. Put the "fix" text, without the comments, from xccdf_org.ssgproject.content_rule_audit_perm_change_success into /etc/audit/audit.rules
   • Alternatively, change the key to something that matches your internal policy corrleators
   • Alternatively, change -F key=XXX to -k XXX (which is completely valid)
   • Alternatively, break the syscalls up into individual lines like they were required to be in EL7
   • Alternatively, put the rules into any file that's not explicitly /etc/audit/rules.d/30-ospp-v42-5-perm-change-success.rules
     • NOTE: Requiring explicit filenames is bad for automation
2. Run oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_stig --rule xccdf_org.ssgproject.content_rule_audit_perm_change_success ssg-rhel8-ds.xml

Actual Results:

Failure

Expected Results:

Pass

[vojtapolasek]

Hello,
issue 1: I agree that the way in which Audit rules are checked in this case could be improved. Just to clarify, this way of check / remediation is currently used only in rhel8 ospp profile. You can still use individual rules where each line represents one audit rule from within the auditd_configure_rules group.
Remediating and checking of Audit rules is quite problematic. If you go in the way it is in rhel7, you can customize the set of rules, but it is not that performance efficient because you have many lines with Audit rules.
In case of rhel8, the performance is better but customization is limited. At the same time, you have hardcoded ordering of rules, that's something you can't influence in rhel7.
If you have any suggestions how to improve this, they are welcomed.
Issue 2: We are using OVAL for checking of the system. OVAL cannot execute commands, so I am afraid that checking runtime state of Audit rules is not an option here.
We decide conditionally if we check rules in /etc/audit/audit.rules or in /etc/audit/rules.d/, depending on the fact if augen-rules is used or not.

[trevor-vaughan]

It looks like this might help OVAL-Community/OVAL#114 as referenced in #6597. I don't have a great solution but the team needs to remember that a lot of people take this as "the only way" so whatever is done needs to be done with care for the reality of the system regardless of whether or not it gives flexible language.

[vojtapolasek]

Yes, I agree that if this new test is accepted in a form which allows to check for rules flexibly, it might open very interesting possibilities in this area. We are watching it closely.

[Mab879]

Thanks for opening this issue.

However, due to OVAL limitations this issue cannot be addressed.

We only check comments for things like OSPP and this is by design since we are checking the whole file.