SELinux and AppArmor: Mandatory Access Control for Linux Defense in Depth

1. Introduction

Traditional Unix permissions answer whether a user or group may access a file. Mandatory Access Control adds another policy layer that can restrict even processes running as root. SELinux and AppArmor are the two common Linux MAC frameworks, and both can reduce the blast radius of a compromised service. This article focuses on defensive administration, auditing, and authorized lab work. The objective is to understand the control, identify misconfiguration before it becomes an incident, and build a repeatable hardening process that can be applied across real Linux environments.

2. How It Works

SELinux labels subjects and objects with security contexts and evaluates policy rules to decide allowed actions. AppArmor uses path-oriented profiles that define what a program may access. Both support enforcement and logging, though their management models differ significantly. Linux security is layered, so this control should be considered together with identity, filesystem permissions, service configuration, kernel policy, network segmentation, and centralized monitoring. A single command rarely tells the whole story; the effective security posture comes from how these layers interact.

3. The Security Problem

Organizations sometimes disable MAC controls because a policy blocked an application during deployment. That removes a valuable containment layer. Another problem is leaving systems in permissive or complain mode indefinitely, where violations are logged but not blocked. These weaknesses are often created gradually by troubleshooting, legacy migrations, vendor installation scripts, or temporary exceptions that later become permanent. A good security review therefore looks not only for obviously dangerous settings, but also for configuration that no longer has a clear owner or business justification.

4. How Attackers Abuse It

If an attacker exploits a web service, a strong MAC profile may prevent access to SSH keys, database files, or system configuration even when standard permissions would otherwise allow it. Attackers with root may try to disable enforcement, so changes in MAC state are high-value signals. In an authorized assessment, the goal is to demonstrate exposure safely and report the exact condition that creates the risk. In production incident response, avoid making destructive changes before collecting enough context to understand whether the issue is a simple misconfiguration, active abuse, or a persistence mechanism.

5. How to Detect / Enumerate & Audit It

Command

getenforce 2>/dev/null || aa-status 2>/dev/null

What it does: Show SELinux or AppArmor enforcement state.

What to look for: Disabled or permissive/complain-only posture.

Defensive use: Verify the control is active.

Command

sestatus 2>/dev/null || true

What it does: Display detailed SELinux status.

What to look for: Policy mode, loaded policy, and enforcing state.

Defensive use: Audit SELinux configuration.

Command

aa-status 2>/dev/null || true

What it does: List AppArmor profiles and modes.

What to look for: Unconfined applications or complain-mode profiles.

Defensive use: Audit AppArmor coverage.

Command

journalctl -k | egrep 'AVC|apparmor="DENIED"' | tail -n 50

What it does: Review recent MAC denials.

What to look for: Legitimate policy gaps or suspicious access attempts.

Defensive use: Tune policy and investigate behavior.

A useful operational habit is to save the output of these checks in a baseline for each server role. A database server, bastion host, developer workstation, and container node will not look identical, so comparison should be against a known-good peer or documented configuration rather than against a generic assumption.

6. How to Audit the Environment

• Keep enforcement enabled on production systems unless a documented exception exists.
• Review high-value network-facing services for policy coverage.
• Investigate repeated denials instead of automatically allowing everything.
• Use distribution tooling to manage labels and profiles.
• Monitor enforcement state and policy changes.
• Document every exception with an owner, reason, and review date.
• Re-check the control after upgrades because packages and deployment automation can silently change defaults.

7. How to Fix / Harden It

• Write narrow local policy adjustments rather than disabling the framework.
• Restore correct SELinux labels with supported tools instead of broad relabel hacks.
• Move AppArmor profiles from complain to enforce after validation.
• Include MAC policy in application deployment testing.
• Protect policy files with configuration management.
• Apply changes through configuration management when possible so the desired state is reproducible.
• Test hardening first on a staging host or a disposable snapshot and verify that critical services still function.

8. Detection & Monitoring

• Alert if SELinux changes from enforcing or AppArmor profiles are disabled.
• Review denial logs for unusual file, network, or capability access.
• Correlate MAC denials with application exploits or misconfigurations.
• Keep time synchronization reliable so host events can be correlated with firewall, identity, EDR, and SIEM data.
• Send high-value security logs off-host because a fully compromised root account can often alter local evidence.

9. MITRE ATT&CK Mapping

MITRE ATT&CK is most useful here as a common language for detection engineering and incident reporting. The mapping does not mean every misconfiguration is an active attack; it shows which attacker behaviors may become easier when the control is weak.

10. Practical Lab

In an isolated Linux lab or disposable VM:

1. Check which MAC framework your lab distribution uses.
2. Put a simple test profile into complain/permissive mode and generate a controlled denial.
3. Review the log event.
4. Adjust policy narrowly and return to enforcement.
5. Verify normal application behavior still works.
6. Capture screenshots or command output before and after the change so you can prove what the control actually changed.
7. Revert the VM or remove the test configuration when finished.

11. Key Takeaways

• SELinux and AppArmor should be treated as part of a layered security model, not as an isolated setting.
• Inventory the current state first, because unknown configuration is difficult to secure.
• Prefer least privilege, explicit ownership, and documented exceptions.
• Monitor changes to the control itself; attackers often try to weaken defenses after gaining access.
• Test fixes in a lab and verify the effective runtime state, not only the configuration file.

Continue learning: Linux Security

This guide is part of our Linux Security series. Related guides in this series cover permissions, sudo, SUID/SGID, Linux capabilities, SSH, PAM, systemd, logging, firewalls, DNS, process security, filesystems, encryption, auditd, kernel hardening, containers, mandatory access control, package security, incident response, and backup protection.