Check if audit config is locked

[andrewkroh]

If the audit config is locked (audit_status.Enabled == 2) then the auditd metricset should either not attempt specific config changes or should continue on EPERM errors. The goal is to allow Auditbeat to read events even if the config has been locked in the kernel.

• https://github.com/linux-audit/audit-kernel/blob/bebc6082da0a9f5d47a1ea2edc099bf671058bd4/kernel/audit.c#L379

[adriansr]

After playing a little bit more with audit and locking, I'm afraid that auditing through an unicast socket is not possible, even if errors are ignored or configuration skipped, the events themselves will not be received.

Once the config has been locked, not only rules cannot be added, but also the status fields cannot be changed. This includes the PID of the active auditing process. In this case, the PID is either that of the audit process that was active at the time of locking or zero if no audit process has been set, or it terminated already. The only way to unlock the configuration and register a new PID is to restart the system.

This rules out all auditing using the unicast socket, as Auditbeat cannot register its PID.

The good news is, on the multicast side, no changes are necessary for the current Auditbeat to be able to receive audit events when the config is locked. Even if the audit process has terminated (PID=0), events are still received.

So my suggestion is either transition to multicast when the configuration is locked or fail and suggest the operator use a multicast socket.

[andrewkroh]

I think falling back to the multicast socket would be good (and logging a warning about why). I'm surprised that the kernel doesn't allow the PID to be set since this prevents the audit daemon from restarting.