Multiple "-module: auditd" stanzas in config file lead to problems

[barely47 (Barry Lustig)]

A user of mine took a provided auditbeat.yml config file and converted it into something that included:

  - module: auditd
    enabled: true
    audit_rules: "-a always,exit -F arch=b32 -S all -k 32bit-abi"
    user.detect_password_changes: false
    scan_at_start: false
    recursive: true
  - module: auditd
    enabled: true
    audit_rules: "-a always,exit -F arch=b64 -S execve,execveat -k exec"
    user.detect_password_changes: false
    scan_at_start: false
    recursive: true

If you start auditbeat using this, you'll see output along these lines from auditbeat show auditd-status:

enabled 1
failure 0
pid 0
rate_limit 0
backlog_limit 8192
lost 381
backlog 0
backlog_wait_time 0
features 0xf

The pid value is 0. To the kernel, that means there is no user-space audit listener. When the linux kernel sees a pid value of 0 here and auditing is still enabled, it will printk the audit record into the kernel message buffer leading to journald spamming various logs in /var/log.

It looks to me like auditbeat is trying to instantiate two modules:

2021...	INFO	instance/beat.go:299	Setup Beat: auditbeat; Version: 7.10.2
2021...	INFO	[publisher]	pipeline/module.go:113	Beat name: dca1-security-prod-intel01
2021...	INFO	[auditd]	auditd/audit_linux.go:106	auditd module is running as euid=0 on kernel=4.9.0-16-amd64
2021...	INFO	[auditd]	auditd/audit_linux.go:133	socket_type=unicast will be used.
2021...	INFO	[auditd]	auditd/audit_linux.go:106	auditd module is running as euid=0 on kernel=4.9.0-16-amd64
2021...	INFO	[auditd]	auditd/audit_linux.go:133	socket_type=unicast will be used.

The second instantiation steps on the first leading to pid == 0.

I don't think this is what is expected. Either it is a syntax error to have two "module: auditd" clauses, or auditbeat should cleanly have the second clause supersede the first or both should be able to happily coexist.

Worth a bug report?