RHEL-09-653030: fails if /var/log/audit is not in its own mount

[PrymalInstynct]

Describe the Issue
When running the tasks for RHEL-09-653030 the remediation fails if /var/log/audit is not in its own partion

Expected Behavior
The task is successful even if /var/log/audit is not in its own partition

Actual Behavior
The task fails

TASK [RHEL9-STIG : MEDIUM | RHEL-09-653030 | AUDIT | RHEL 9 must allocate audit record storage capacity to store at least one week's worth of audit records.] ***********************************************************************************************
Saturday 16 March 2024  09:26:44 -0600 (0:00:00.890)       0:06:07.380 ******** 
fatal: [rocky9-stig.prymal.linux]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: {{ ansible_facts.mounts | selectattr('mount','equalto',rhel9stig_audit_log_filesystem) | list | first }}: No first item, sequence was empty.. No first item, sequence was empty.. {{ ansible_facts.mounts | selectattr('mount','equalto',rhel9stig_audit_log_filesystem) | list | first }}: No first item, sequence was empty.. No first item, sequence was empty.

The error appears to be in '/home/zimmermanc/Projects/cybersecurity/RHEL9-STIG/tasks/Cat2/RHEL-09-65xxxx.yml': line 627, column 7, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

  block:
    - name: \"MEDIUM | RHEL-09-653030 | AUDIT | RHEL 9 must allocate audit record storage capacity to store at least one week's worth of audit records.\"
    -       ^ here
    "}

Control(s) Affected
RHEL-09-653030

Environment (please complete the following information):

• branch being used: main
• Ansible Version: 2.16.4
• Host Python Version: Python 3.11.8
• Ansible Server Python Version: Python 3.11.8

Additional Notes
None

Possible Solution
None

[uk-bolly]

hi @PrymalInstynct

Thank you for taking the time to raise this issue.

Have you changed the the variable
rhel9stig_audit_log_filesystem
to where you store your audit logs?

this potentially could be a better change to run a prelim task to confirm the setting is relevant?

Many thanks

uk-bolly

[PrymalInstynct]

I did not change that variable because the default is correct for my system.

[Coconutcoo]

Just hit this myself - on our system /var/log/audit is just a part of the mount at /.

I'm not sure which of the following is the intention of this directive;

1. Guarantee we have space for 1 weeks' worth of audit logs by having a separate mount that shouldn't be filled up by other data (in which case, this should fail, but perhaps the wording needs to change?)
2. Ensure we aren't using such a tiny disk that audit logs literally couldn't be generated "right now" (in which case, the task should just look up what mount /var/log/audit is under (e.g. df /var/log/audit --output=target?) and check the free space of that?

Edit:
Having looked at the V2R1 copy of the STIG from the DoD Cyber Exchange, they actually suggest point 2 above;

If audit records are stored on a partition made specifically for audit records, resize the partition with sufficient space to contain one week of audit records.

If audit records are not stored on a partition made specifically for audit records, a new partition with sufficient space will need be to be created.

and

Determine which partition the audit records are being written to with the following command:

$ sudo grep log_file /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log 

Check the size of the partition that audit records are written to with the following command and verify whether it is sufficiently large:

 # df -h /var/log/audit/
/dev/sda2 24G 10.4G 13.6G 43% /var/log/audit 

If the audit record partition is not allocated for sufficient storage capacity, this is a finding.

I would argue then that the current implementation here doesn't quite fit that logic - it needs to look up the mount point that rhel9stig_audit_log_filesystem is under, and then check for >10GB of free space there.

[uk-bolly]

hi @Coconutcoo

Thank you for feeding back on this issue. We are currently running version v1r3 in public moving to v2rx soon.
This is a great query and one that can be awkwardto try and cover off scenarios:

• The name of the logfile path may not be the mount name e.g. /var/log/audit/logs/audit.logs we would need to discover what the mount is as not all follow the expected path.
• We are also not able to determine the amount of space free is sufficient to last a week depending on the users configuration and the amount of logs that they keep.

However the solution does look up the mount for the audit_log_filesystem as set by the user and captures the space left using that information.

The solution that we have should, we hope cover most popular ways to cover it off and the output does appear as a warning to confirm investigation required.
If you have an idea on how we could extend this further whilst keeping the simplicity that would be excellent.

Kindest regards

uk-bolly