TL;DR
This guide shows you how to create auditd rules that work correctly on both 32-bit and 64-bit systems. We’ll focus on using the correct architecture specifiers in your rule files.
Setting up Auditd Rules for Both Architectures
- Understand Architecture Specifiers
- auditd uses architecture specifiers to target rules to specific processor types.
b64: 64-bit architectures (e.g., x86_64, amd64)b32: 32-bit architectures (e.g., i386, i686)all: Applies to all architectures. Use with caution as it can impact performance.
Determine the architecture of your systems using:
uname -m
This will output something like x86_64 (64-bit) or i686 (32-bit).
It’s best practice to create separate rule files for architecture-specific rules. For example, you might have:
/etc/audit/rules.d/64bit_rules.rules/etc/audit/rules.d/32bit_rules.rules/etc/audit/rules.d/common_rules.rules(for rules that apply to both)
Here’s how to write rules targeting specific architectures:
- 64-bit Rule Example: Monitor execution of a specific program on 64-bit systems.
-a always,exit -F arch=b64 -S execve /path/to/program
-a always,exit -F arch=b32 -S open /path/to/file
-a always,exit -F arch=all -S syscall
After creating or modifying rule files, reload auditd:
sudo auditctl -R /etc/audit/rules.d/*
Verify that your rules are working as expected by triggering the events they’re designed to capture.
- Run the program or access the file you’ve created a rule for.
- Check the audit logs using
ausearch:
sudo ausearch -i
- If rules aren’t firing, double-check the architecture specifier. Ensure it matches your system’s architecture.
- Use
auditctl -lto list currently loaded rules and verify they are active. - Check for syntax errors in your rule files using
auditd -n(dry run).