Select AppArmor correctly to stop the kernel audit flood

[devantler]

🤖 Generated by the Agentic Engineer

Description

Coroot reports a recurring audit: rate limit exceeded alert and a log-error indicator on the host init application. These are current events, not retained rollout history: the September 25 sample contains fresh rate-limit errors and SELinux permissive AVC denials from ordinary Coroot cache access. Audit loss also means security records are being dropped.

Steps to reproduce

1. Inspect the production Talos patch and factory schematic at the current main revision.
2. Observe that lsm= puts SELinux before AppArmor and BPF before AppArmor.
3. Read the Coroot init logs for the current hour. The warning is a kernel audit rate limit, not a GitHub API quota response.

Expected behavior

The declared AppArmor configuration should actually select AppArmor and preserve the other compatible hardening modules. Audit logging should remain enabled without a continuous permissive SELinux denial stream or the earlier audit subject-context error.

Actual behavior and environment

All seven production nodes are Ready and run Talos v1.13.10 / Linux 6.18.48 with the declared factory image. This rules out the stale rollout repaired by #4098/#4099. Coroot currently reports one non-OK application for log errors; the latest compact sample also reports warning alerts. Application SLO, warning, integration-required and risk counters are zero.

The configured order is yama,selinux,loadpin,safesetid,integrity,bpf,apparmor,lockdown,landlock. Linux marks SELinux and AppArmor exclusive, so SELinux wins. Separately, the audit context conversion takes the first matching LSM hook; BPF before AppArmor can reproduce the earlier audit-context failure.

Repair and acceptance criteria

• Select AppArmor before SELinux and BPF in both the machine patch and factory schematic, without disabling audit or relaxing Coroot checks.
• Replace the existing order-only assertion with regressions for exclusive-LSM selection and audit-hook precedence; demonstrate RED then GREEN and negative controls.
• Keep Talos version, compatible hardening modules, audit rate and backlog settings unchanged.
• Validate rendered configuration and the registered factory schematic; require exact-head substantive non-Copilot review and CI before the protected deployment path.
• Verify the actual deployed image and node health, then observe separated Coroot samples with no new audit flood or audit subject-context errors. Retain historical evidence until it ages out.

References

• Linux 6.18.48: security/security.c, security/apparmor/lsm.c, security/selinux/hooks.c.
• Talos AppArmor setup: v1.9.0-alpha.2 siderolabs/talos#9680
• AppArmor-before-BPF correction confirmed by the reporter: [BUG] kernel spams "audit: error in audit_log_subj_ctx" on 7.0.11 despite correct lsm=/apparmor config CachyOS/linux-cachyos#878

Estimated scope: small configuration/test correction, with production rollout and observation required to close.