On Wed, May 28, 2025 at 2:46 PM Steve Grubb via Linux-audit
<linux-audit(a)lists.linux-audit.osci.io> wrote:
Hello,
We just released a new version of the audit daemon. It can be
downloaded from
https://github.com/linux-audit/audit-userspace/releases/tag/
v4.0.4
The ChangeLog is:
- auditctl: update io_uring operations table
- update syscall table for 6.15
- auditd.cron.5: Describe time-based log rotation setup
- auditd: Broadcast a warning on startup if a system halt is possible (#435)
- Fix audisp-remote segfault on connection error (#446)
- Improve locating last event if ausearch is using checkpointing
- af_unix plugin: fix string mode support
- Remove const from audit_rule_fieldpair_data & audit_rule_interfield_comp_data
- Add various updates to the experimental ids plugin
- Add glibc memory statistics to auditd state report
This updates lookup tables, fixes a misbehaving af_unix plugin, improves
locating the last event when using the checkpoint feature of ausearch, adds
updates to the experimental ids plugin, and adds memory statistics to the
auditd state report. The idea here is to be able to detect growing memory
over time.
There was also reworking of the audit_fgets helper functions. They are used
in auditd plugins. So, if any plugins seem like something is wrong, file an
issue on github.
This clears out a backlog of updates. There are some major rewrites of
functionality that will take place over the summer. If you an inclination,
tryout the main branch from time to time to help spot any new issues.
If you notice any problems with this release, please let us know.
I'm not sure if this is an intentional change, but I don't see it
explicitly listed in the changelog above so I wanted to mention this
in case it was a bug.
I recently upgraded audit from version 4.0.3-2.fc42 to 4.0.4-1.fc43 on
my Fedora Rawhide test system and I started to see "Option
exclude,always is invalid" errors when I had not previously. Is this
expected behavior, and if so, what is the suggested alternative to
'auditctl -a exclude,always'?
For reference, here is the last known good test run with version 4.0.3-2.fc42:
*
https://groups.google.com/g/kernel-secnext/c/KCk5MZbnv5w
... and here is the first failing test run with version 4.0.4-1.fc43:
*
https://groups.google.com/g/kernel-secnext/c/hyDNpgH-rjk
I've also reproduced this manually by only changing the audit packages
on my system to help rule out kernel, library, or other changes; it
does appear to be related to the audit 4.0.4-1.fc43 release/build.
--
paul-moore.com