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.