In this lesson, you will learn how to navigate the technical constraints and logic conflicts that arise when attempting to run multiple Mandatory Access Control (MAC) systems concurrently.
The Conflict of Sovereignty
Linux security modules like AppArmor and SELinux are designed to enforce "sovereign" control over system objects (files, sockets, processes). Because they both hook into the Linux Security Module (LSM) framework at the kernel level, they cannot simply be "layered" on top of one another to provide double the protection. In modern kernels, while you can enable multiple modules, you are generally limited to one "major" module that performs the primary mediation (e.g., SELinux) and potentially others that only handle specific, non-overlapping tasks.
Understanding Policy Collision
The core challenge of policy interoperability is conflicting authority. If you have an AppArmor profile denying access to /etc/shadow and an SELinux policy allowing it, the kernel must decide which module wins.
Usually, the LSM framework follows a "fail-closed" architecture: if any loaded module denies an operation, the operation is blocked, regardless of whether another module allows it. This creates a "shadowing" effect where debugging becomes a nightmare. If you enable both:
# Checking active LSMs
cat /sys/kernel/security/lsm
# Typical output: capability,selinux,apparmor
If selinux is the primary module and apparmor is the secondary, any rule set in AppArmor will act as an additional restrictive layer. If your AppArmor profile is too permissive, it won't help if SELinux blocks the access; conversely, if your SELinux policy is too broad, it won't prevent an AppArmor profile from enforcing stricter constraints.
Best Practices for Interoperability
- Prefer Singular Enforcement: Avoid the "double-stacking" of policy engines. Pick the framework that best matches your organization's compliance requirements and consolidate all logic there.
- Audit Before Merge: If you must transition or run a hybrid setup, use
audit=1in your kernel boot parameters to capture logs from both systems simultaneously. This prevents the "silent block" where you blame the wrong MAC system for a denied process. - Namespace Isolation: Use mount namespaces to segregate processes that require different security enforcement engines, rather than attempting to force a single process to satisfy two conflicting MAC policies.
Key Takeaway: Policy interoperability is rarely about additive protection and almost always about managing the "most restrictive" outcome of overlapping LSM hooks; avoid concurrent enforcement unless using strictly defined, non-overlapping modules.