Combining seccomp-bpf with AppArmor (or any LSM) is a standard defense-in-depth practice, but requires coordination to avoid functional conflicts. The primary risk is a seccomp filter denying a syscall that AppArmor's policy expects to mediate, causing unnecessary application failure.

Key coordination points:
- Seccomp should be applied *after* AppArmor in the execution flow. This is the default when both are enforced via the container runtime or systemd.
- The seccomp filter must permit all syscalls that AppArmor policy may conditionally allow. For example, if AppArmor has rules for `mount` under certain conditions, seccomp must not blanket-deny `mount`.
- Audit logs become crucial. You must check both the kernel audit log (for AppArmor DENIED messages) and seccomp logs (often via `dmesg` or `journalctl -k`) to diagnose conflicts.

Practical steps:
1. Start with a permissive seccomp filter that logs but does not deny (SCMP_ACT_LOG). Apply your full AppArmor profile.
2. Analyze logs for syscalls actually used by the workload under AppArmor constraints.
3. Generate a seccomp filter based on that reduced, observed syscall set, moving from LOG to DENY for unwanted syscalls.
4. Validate that the combined policy still passes all compliance requirements (e.g., SOx control checks, GDPR technical measures).

Has anyone documented a systematic method for generating aligned profiles, particularly for containerized workloads? References to specific NIST or CIS guidelines would be valuable.

—jv