Auditd immutable mode should be a planned deployment step

Audit rules are useful only if they remain the rules the operator intended to deploy. Linux auditd offers an immutable mode that prevents audit configuration changes until reboot. The setting is strong enough to cause real operational pain when it is introduced without a change plan.

What immutable mode does

auditctl -e 2 locks the audit configuration. The auditctl manual describes the enabled values: audit is off at 0, rules can be loaded or changed at 1, and 2 locks the configuration so that it cannot be changed. After the lock is applied, the configuration remains locked until the system reboots.

That property is valuable because an attacker who reaches a privileged account may try to disable logging or alter the rules that would record later activity. Immutable mode does not make the kernel or every privileged process trustworthy, and it does not prevent all forms of tampering. It does remove a simple configuration change from the live attack path.

The setting also changes the deployment process. A configuration management run that tries to append, delete, or replace rules after the lock may fail. An operator may discover the problem while responding to an incident, which is the worst time to learn that the automation cannot update the audit policy.

Separate rule design from rule activation

Build the final rule set before enabling the lock. Use stable filter keys for the activity the team actually wants to find, such as privileged execution, credential-file access, or changes to security-sensitive paths. A key should describe a review case, not a generic category that produces thousands of unread events.

The ordering matters. A common pattern is to load rules, verify them, and only then lock the configuration:

augenrules --load
auditctl -l
auditctl -s
auditctl -e 2

These commands should run under a controlled service unit or configuration-management step that records the resulting rule set. The auditctl -l output and service status belong in the deployment record. Do not use an unverified shell loop that hides errors and continues to the lock command.

auditctl -e 2 is not a substitute for protecting /etc/audit and the service configuration. The filesystem permissions, package ownership, and remote log path remain separate controls. If logs are stored only on the same host and are writable by the compromised service, immutable rules may preserve configuration while the evidence disappears.

Plan rollback and maintenance

Once the configuration is locked, routine rule changes require a reboot. Build that into maintenance windows. A change that would normally take seconds becomes a coordinated rollout.

Test the lock on a disposable host. Confirm that a benign rule change fails after -e 2, then reboot and confirm that the intended rule load succeeds. Check whether the init system or container entrypoint runs auditctl -e 1 after the lock, which would silently undo the control. Verify the effective state with auditctl -s, not just the configuration file on disk.

Container hosts need a separate review. A container may not control the host audit rules, and a privileged container may be able to interact with the host audit subsystem. Do not infer host-level immutability from a container's local configuration.

Make the control observable

Record the boot ID, rule hash, activation time, and service result when the lock is applied. Alert on a reboot that does not reapply the approved rules. Forward audit events to an independent collector so that host loss does not erase the evidence trail.

Review the rule set after incidents and after major package upgrades. A rule that no longer matches the current process path can create a false sense of coverage. The immutable setting should protect a curated configuration, not preserve a stale one indefinitely.

References

• Linux man-pages, auditctl(8)
• Linux man-pages, auditd.conf(5)
• Linux man-pages, auditd(8)