CrackArmor: 9 Flaws Shattering AppArmor and Container Isolation
Has anyone else dug into the Qualys report on 'CrackArmor' yet? It’s pretty sobering news for anyone relying heavily on AppArmor profiles for containment. The researchers at Qualys TRU dropped details on nine vulnerabilities (CVE-2026-2143 through CVE-2026-2151) that fundamentally break the trust model of the Linux Security Module (LSM).
The core issue is a series of 'confused deputy' scenarios. An unprivileged user can manipulate AppArmor into granting permissions it shouldn't, effectively tricking the kernel into escalating privileges to root. More critically for us, this undermines container isolation. If an attacker compromises a container process, they can abuse these flaws to break out to the host.
It’s a reminder that kernel isolation is complex. If you are managing Docker or LXC hosts, you need to verify your patch status immediately. I put together a quick snippet to check for vulnerable kernel indicators and active enforcement status:
#!/bin/bash
# Check for vulnerable kernel versions (example range /dev/null; then
echo "AppArmor Profiles Loaded:"
aa-status -- | jq '.profiles | to_entries[] | select(.value=="enforce") | .key' | head -n 5
else
echo "AppArmor not found."
fi
# Audit logs for suspicious execve anomalies
echo "Recent AppArmor audit failures:"
ausearch -m avc -ts recent | grep apparmor | tail -n 5
Beyond patching, we’re looking at userns remapping as a temporary mitigation. Is anyone else considering disabling AppArmor enforcement until the dust settles, or is the performance hit of alternatives like seccomp-bpf too high?
We've actually moved away from AppArmor for our critical workloads precisely because of profile complexity and issues like this. We're relying strictly on Seccomp filters combined with user namespaces now. It's significantly harder to configure initially—you have to map every syscall—but it feels less brittle than these permission models that rely on complex policy parsing.
The 'confused deputy' angle here is fascinating. It's not a standard memory corruption bug you can just KASLR away; it's a logic flaw in how the LSM hook handles delegation. I'll be spinning up a test VM to verify the PoCs. Defenders should watch for unusual execve anomalies in their audit logs, specifically processes spawning children that violate their defined profile constraints.
Great write-up. For those on Kubernetes, remember that many distros enable AppArmor by default on the pods. If you can't patch the host kernel immediately, you might want to enforce securityContext with readOnlyRootFilesystem and drop: ALL capabilities to add defense-in-depth layers while you wait for the vendor fix. Don't rely on the profile alone right now.
Great points on Seccomp, but remember it doesn't restrict file access. For modern containment, I’d recommend looking into Landlock as a complementary LSM; its object-based approach avoids the path-based delegation mess affecting AppArmor. Until then, you can audit your specific profiles for excessive mount permissions that enable these confused deputy attacks using:
aa-status -- | jq '.profiles | to_entries[] | select(.value == "enforce") | .key'
This helps identify exactly what's enforcing containment while you wait for kernel patches.
Before fully migrating away from AppArmor, you can mitigate the impact by auditing current profiles for overly broad px (execute) transitions. Often, these confused deputy exploits rely on pivoting through allowed executables to escalate privileges. You can quickly scan for potential risks in your active profiles using:
sudo grep -r "px" /etc/apparmor.d/
Reviewing the output for paths pointing to user-writable binaries is a solid stopgap until your kernel updates are deployed.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access