What CrackArmor Teaches Us About Linux Security Assumptions

What Is the CrackArmor AppArmor Bypass?

CrackArmor is a set of nine critical vulnerabilities in AppArmor, the mandatory access control system enabled by default on Ubuntu, Debian, and SUSE. Disclosed by Qualys and present since Linux kernel 4.11 (2017), the flaws let an unprivileged local attacker bypass AppArmor entirely to gain root, break container isolation, or crash the system — no credentials required.

What CrackArmor Actually Does 

The CrackArmor vulnerabilities target the AppArmor Linux Security Module itself -- the mechanism that's supposed to enforce security boundaries. 

According to Qualys, an attacker can: 

• Strip protections from critical system services, removing the security profiles that restrict what processes like SSH and system daemons can do 
• Lock all users out of remote access by targeting the SSH daemon's AppArmor profile 
• Bypass Ubuntu's restrictions on unprivileged user namespaces, even after all previously known workarounds were closed 
• Read protected kernel memory, exposing internal addresses that security mitigations like ASLR are designed to hide -- making follow-on exploits significantly easier 
• Achieve full root access through two independent paths, even on systems with modern exploit mitigations enabled by default 
• Crash the entire system by forcing a reboot 

The researchers noted: "These findings expose critical gaps in our reliance on default security assumptions. It fundamentally undermines system confidentiality, integrity, and availability." 

Over 12 million enterprise systems running Ubuntu, Debian, and SUSE are affected.  

Why This Matters Beyond Patching 

The standard response to a vulnerability disclosure is: patch it. And organisations should absolutely apply the CrackArmor patches immediately. 

But the deeper lesson is about the security model itself. 

AppArmor has been positioned as a compensating control -- something that limits the blast radius even when other defences fail. Security audit responses frequently cite it alongside other defaults: "AppArmor is enabled in enforcing mode. SELinux policies are configured." 

The CrackArmor disclosure demonstrates that this assumption was wrong for nine years. Every compliance evidence package that cited AppArmor as a mitigating control during that period was based on a faulty premise. 

This is not unique to AppArmor. The broader pattern is this: organisations treat enabled defaults as verified security. They assume that because a control exists in the configuration, it's functioning as intended. 

On Linux systems specifically, this assumption-based approach extends across the entire privilege landscape: 

• Sudo configurations are assumed to follow least privilege, but rarely audited at scale 
• SSH keys are assumed to be managed, but many environments have no inventory of which keys grant access to which servers 
• Service accounts are assumed to have appropriate privileges, but often accumulate permissions far beyond their original purpose 
• Container isolation is assumed to be enforced by the kernel and AppArmor – and CrackArmor just demonstrated that assumption can be broken 

The Compliance Implications 

For organisations operating under NIS2, SOC 2, or CIS Benchmarks, CrackArmor creates a specific evidentiary problem. 

NIS2 Article 21 requires risk management measures covering access control and vulnerability handling. Germany's implementation – now covering 29,500 companies with fines up to EUR 10 million -- demands evidence that these measures are systematic and actively managed. 

CIS Benchmark Level 1 for Ubuntu requires AppArmor to be enabled with profiles in enforce or complain mode. An organisation that has been reporting CIS compliance based on AppArmor's status was unknowingly relying on a compromised control. 

SOC 2 CC6.1 requires logical access controls that restrict access to information assets. If the mandatory access control mechanism itself can be bypassed by an unprivileged user, the control is ineffective. 

The EDPB and EDPS joint opinion on NIS2 amendments, published on March 18, reinforces the direction of travel: mandatory ransomware reporting, expanded scope to European Digital Identity Wallet and Business Wallet providers, and continued emphasis on demonstrable, auditable security measures. 

Meanwhile, the Stryker attack this month – approximately 80,000 devices wiped via compromised administrator accounts, with recovery estimated at $24-40 million – demonstrates the real-world cost when privileged access isn't inventoried and controlled. 

That is the deeper problem — how to evidence that a control actually enforces, not just that it is installed.

Beyond Assumptions: A Verification Checklist 

CrackArmor is a catalyst for moving from assumed security to verified security on Linux systems. Here's a practical starting framework: 

1. Patch AppArmor immediately. This is the obvious first step. Apply the CrackArmor patches across all Ubuntu, Debian, and SUSE systems. 

2. Audit your AppArmor profile inventory. Which profiles are in enforce mode? Which are in complain mode? Are there critical services running without profiles? The answer often surprises teams. 

3. Inventory all sudo configurations. Collect /etc/sudoers and all files in /etc/sudoers.d/ from every server. Identify any NOPASSWD: ALL entries, legacy users, and overly permissive grants. 

4. Map SSH key distribution. Which keys grant access to which servers? When were they last rotated? Do any belong to former employees or decommissioned service accounts? 

5. Review service account privileges. Are service accounts scoped to the minimum commands they need? Or have they accumulated broad permissions over time? 

6. Document everything for compliance evidence. The audit itself becomes the evidence. Record what was found, what was remediated, and what the verified baseline looks like going forward. 

7. Challenge your other default assumptions. What other "enabled by default" controls are you relying on without active verification? 

How to Verify AppArmor Is Actually Enforcing

Patching closes the CrackArmor flaws, but it does not tell you whether AppArmor was ever enforcing in the first place. Verify it directly on each host:

Run sudo aa-status (or sudo apparmor_status) to list how many profiles are loaded and, crucially, how many are in enforce mode versus complain mode. A profile in complain mode logs violations but blocks nothing.

Confirm the module is active with cat /sys/module/apparmor/parameters/enabled (expect Y), and check that critical services — web servers, mail daemons, container runtimes — are actually covered by an enforcing profile rather than running unconfined.

Then repeat the check across the whole estate, not one sample host. A single server in complain mode, or a critical service with no profile at all, is the gap CrackArmor turns into root. Record the results as your verified baseline so the next audit rests on evidence, not on “enabled by default.”