Multiple Ubuntu STIG rules using wrong auid value

[jgbradley1]

Describe the Bug
I posted this bug over in the ato-toolkit repo but later realized that project uses the output (configuration files) from this project.

This Powershell module incorrectly defines several STIG rules for Ubuntu, specifically for the audit service. Currently STIG rules are defined by comparing against the wrong auid value (-1 instead of 4294967295). Please see the issue linked above for the full list.

To illustrate this bug, please review this STIG rule very carefully. When the audit rule is defined in the file /etc/audit/rules.d/audit.rules, it should contain the lines:

-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b32 -S setxattr -F auid=0 -k perm_mod 
-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S setxattr -F auid=0 -k perm_mod

However this module defines the rules as:

-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=-1 -k perm_mod
-a always,exit -F arch=b32 -S setxattr -F auid=0 -k perm_mod 
-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=-1 -k perm_mod
-a always,exit -F arch=b64 -S setxattr -F auid=0 -k perm_mod

Note: the minute difference is the text auid!=4294967295 vs auid!=-1.

Once audit loads rules from /etc/audit/rules.d/audit.rules, those rules are queried for and verified by external software via auditctl. The output of auditctl would display the above rules as

-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=-1 -k perm_mod
-a always,exit -F arch=b32 -S setxattr -F auid=0 -k perm_mod
-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=-1 -k perm_mod
-a always,exit -F arch=b64 -S setxattr -F auid=0 -k perm_mod

Expected behavior
audit rules should be defined using the auid!=4294967295 format. This powershell module uses the auid!=-1 format though (as seen here).

Additional context
Popular STIG compliance checkers (such as Nessus) perform a regex comparison against audit rules. They usually check both the output of auditctl and the audit rule definitions file. While audit interprets the -1 value and 4294967295 value interchangeably, this leads to hundreds of false positive findings in compliance reports when customers are applying automated STIG deployments (via the ato-toolkit).

[japatton]

I applied the stetting manually and reloaded the rules using 'sudo augenrules --load'. I utilized the 4294967295 value and then performed and auditctl and found that it had changed it to -1. It doesn't appear that this is an issue with PowerSTIG or the STIG itself. Maybe the Nessus scans can be adjusted.

[jgbradley1]

@japatton the problem isn't with the output of auditctl. The output you described is the expected behavior.

In general, there are two "parts" of the audit application that STIG policies apply to.

1. the output format of the audit rules when they're loaded in memory (checked via auditctl) and
2. the format of the audit rules when saved on disk (at /etc/audit/rules.d/audit.rules in this case)

Nessus scans check both. Overall, all scan checks for part 1 pass using PowerSTIG. But several hundred false positive findings will show up for part 2. This is due to STIG policy explicitly requiring audit rules to be defined on disk with the 4294967295 value, even though it is synonymous with -1 in reality.