auditd rules for both 64-bit (b64) and 32-bit (b32) architectures

Question

I'm looking at the OpenSCAP Security Guide for CentOS 7: https://static.open-scap.org/ssg-guides/ssg-centos7-guide-index.html

Under "Record File Deletion Events by User" (as an example), it provides this auditd rule:

-a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=unset -F key=delete

It advises to set "ARCH to either b32 or b64 as appropriate for your system."

I have a 64-bit system (uname -m returns x86_64), but checks fail unless I include rules for both b32 and b64:

Title   Ensure auditd Collects File Deletion Events by User
Rule    xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events
Result  fail

I'm wondering why the b32 line is needed. I tried testing this by setting the architecture to i686 and deleting a file, but it appears to use the 64-bit syscall:

touch audit_i686
setarch i686 rm audit_i686

I'd like to to understand the reason for the 32-bit architecture line and be able to demonstrate the reason for it to any skeptical sysadmins.

Answer 1

I have the same issue on my RedHat machine.

First, you add the 32-bit calls because your software may be using 32-bit calls. There are 32-bit libraries that run under 64-bit architecture. It's difficult to guarantee that your are not using 32-bit calls.

Secondarily, you do it to make the scanner, and the folks reviewing the scan results, happy. Consider how many lines need to be in your audit log, per the scap. You will have 1 finding for every entry missing the arch=b32. Now multiply that by the number of machines on your network. That is a lot of findings.

On my machine, I have 80 findings. I have over 10,000 nodes. That means, my system scans will show a MINIMUM of 800,000 Findings.

I am correcting the ones that I can "make go away," and writing a "Findings Report" to send to the scanner people to fix the scans.

In my scenario, my scanner is being stupid. Your entry:
-a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=unset -F key=delete

Make sense. My Scanner looks for this:
-a always,exit -F arch=B32 -S rmdir -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B64 -S rmdir -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B32 -S unlink -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B64 -S unlink -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B32 -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B64 -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B32 -S rename -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B64 -S rename -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B32 -S renameat -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B64 -S renameat -F auid>=1000 -F auid!=unset -F key=delete

That's TEN entries for what should be TWO lines. I have to write up every single one and say that best practice is to but all the calls on 1 line per architecture.

I need to have the 32 & 64 bit architectures in my audit because we ARE using 32-bit libraries in a 64-bit OS.

I am not going to break them out onto 5 separate lines. Our audit logging is already choking our system. Removing anything I can, or combining lines is what I am working on now.

Unless the scanner gets fixed, we are going to have lots of exceptions.

Ok, now back from that secant. Unless you can PROVE that you have ABSOLUTELY NO 32-bit system calls, you need to double the entries and add both architectures to the audit log.