audit-rules service fails due to unsupported rule group on aarch64

[Levitiku5]

Sponsored by 21Software

Description of problem:

audit-rules.service fails when using the audit_rules_file_deletion_events rule group on Raspberry Pi 5:

root@raspberrypi5:~# systemctl list-units --state=failed
  UNIT                LOAD   ACTIVE SUB    DESCRIPTION     
* audit-rules.service loaded failed failed Load Audit Rules

This is because the group is hardware-agnostic, which means rules for incompatible syscalls on architectures such as aarch64 are not dropped during remediation:

# BEGIN fix (REDACTED) for 'xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_rename'
###############################################################################
(>&2 echo "Remediating rule REDACTED: 'xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_rename'")
# Remediation is applicable only in certain platforms
if rpm --quiet -q audit && rpm -qa "kernel-*" 2>/dev/null | grep -q "^kernel-[0-9]\+\.[0-9]\+\.[0-9]\+-" && { ! ( ( grep -sqE "^.*\.aarch64$" /proc/sys/kernel/osrelease || grep -sqE "^aarch64$" /proc/sys/kernel/arch; ) ); }; then

# BEGIN fix (REDACTED) for 'xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events'
###############################################################################
(>&2 echo "Remediating rule REDACTED: 'xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events'")
# Remediation is applicable only in certain platforms
if rpm --quiet -q audit && rpm -qa "kernel-*" 2>/dev/null | grep -q "^kernel-[0-9]\+\.[0-9]\+\.[0-9]\+-"; then

SCAP Security Guide Version:

0.1.77

Operating System Version:

TSEL (developer build)

Steps to Reproduce:

1. Add the audit_rules_file_deletion_events group to your SSG profile
2. Deploy to a device with aarch64 architecture such as a Raspberry Pi 5
3. Run systemctl list-units --state=failed and observed the failure to load audit rules

Actual Results:

See above.

Expected Results:

N/A

Additional Information/Debugging Steps:

We have gotten around this by specifying each rule in this group individually so that each incompatible rule can be dropped during remediation as appropriate:

audit_rules_file_deletion_events_rename
audit_rules_file_deletion_events_renameat
audit_rules_file_deletion_events_renameat2
audit_rules_file_deletion_events_rmdir
audit_rules_file_deletion_events_unlink
audit_rules_file_deletion_events_unlinkat

This is not ideal, however. As is the case with renameat2, new syscalls may be added to future kernel versions, which would force users to manually define those syscalls in their profile each time this occurs.