Is your feature request related to a problem? Please describe.
Auditd rules that use multiple descriptive keys can exceed the 256-byte rule size limit, preventing valid rules from loading. Searching logs by long key strings also requires repeated string comparisons, which can become slow at scale.
Describe the solution you'd like
Implement compact bitmask labels backed by a userspace registry with immutable versioned snapshots. Tools like auditctl would convert human-readable keys into short labels when loading rules. Tools like ausearch -i would convert those labels back into the original keys for readable searches and reports. Versioned snapshots would preserve old mappings so historical logs remain readable after rule changes.
Describe alternatives you've considered
Using shorter keys helps, but reduces useful tagging for frameworks like MITRE ATT&CK®. Multiple keys such as -k tag1 -k tag2 -k tag3 work well, but complex rules hit the size limit quickly. I also tested hash table and bitmask approaches, but historical log decoding and state management were the main challenges.
I currently have a prototype in progress. The biggest benefits are faster lookups and fitting more useful keys within current limits. Two negatives are maintaining state for current and historical log key correlation, and dealing with malleability with the versioned snapshot tables, but feel if the immutability flag is set appropriate permissions could be set to mitigate the later.
Hoping to create a discussion about a patch to make sure I am hitting the right marks. Thanks for your time.
Is your feature request related to a problem? Please describe.
Auditd rules that use multiple descriptive keys can exceed the 256-byte rule size limit, preventing valid rules from loading. Searching logs by long key strings also requires repeated string comparisons, which can become slow at scale.
Describe the solution you'd like
Implement compact bitmask labels backed by a userspace registry with immutable versioned snapshots. Tools like auditctl would convert human-readable keys into short labels when loading rules. Tools like
ausearch -iwould convert those labels back into the original keys for readable searches and reports. Versioned snapshots would preserve old mappings so historical logs remain readable after rule changes.Describe alternatives you've considered
Using shorter keys helps, but reduces useful tagging for frameworks like MITRE ATT&CK®. Multiple keys such as
-k tag1 -k tag2 -k tag3work well, but complex rules hit the size limit quickly. I also tested hash table and bitmask approaches, but historical log decoding and state management were the main challenges.I currently have a prototype in progress. The biggest benefits are faster lookups and fitting more useful keys within current limits. Two negatives are maintaining state for current and historical log key correlation, and dealing with malleability with the versioned snapshot tables, but feel if the immutability flag is set appropriate permissions could be set to mitigate the later.
Hoping to create a discussion about a patch to make sure I am hitting the right marks. Thanks for your time.