# Security: Ubuntu’s CrackArmor fixes deserve a real runbook if you run Kubernetes or OpenStack on Ubuntu

- Link: https://thestackobserver.com/security-ubuntus-crackarmor-fixes-deserve-a-real-runbook-if-you-run-kubernetes-or-openstack-on-ubuntu/
- Published: 2026-03-13T10:03:41-04:00
- Author: Stackxx

Canonical’s new advisory on the AppArmor issues being referred to as CrackArmor 
is worth reading less as a security bulletin and more as an operator checklist. 
The vulnerabilities require local unprivileged access, but the risk picture changes
sharply depending on whether you run plain hosts, privileged helper paths, or container
environments that may execute attacker-controlled workloads. If you run Kubernetes
or OpenStack infrastructure on Ubuntu, that distinction is not abstract. It is your
threat model.

The advisory’s headline recommendation is refreshingly blunt: apply both the Linux
kernel security updates and the userspace mitigations, and do not confuse the latter
for a full fix. That is the right read. Userspace hardening helps. Kernel updates
are the actual remediation for the underlying AppArmor issues.

## What Canonical says is affected

The write-up describes a cluster of problems:

 * AppArmor vulnerabilities in the Linux kernel, tracked as CrackArmor without CVE
   IDs yet
 * a separate `sudo` issue that can help local privilege escalation in host scenarios
   when chained with the AppArmor bugs
 * unsafe `su` behavior in `util-linux` that can facilitate exploitation in host
   deployments

For operators, the most important split is this:

 * **Hosts without container workloads:** exploitation generally needs a cooperating
   privileged application path
 * **Container deployments:** attacker-controlled container images may create a 
   more direct risk path, including theoretical container-escape scenarios

That second bullet is why Kubernetes and some OpenStack-adjacent estates should 
take this more seriously than a generic workstation patch note.

## Goal

Turn Canonical’s CrackArmor guidance into an explicit patch workflow for Ubuntu-
based cluster and cloud hosts, including exposure checks, package updates, and the
reboot requirement for kernel remediation.

## Prereqs

 * An inventory of Ubuntu hosts by role: control plane, worker, hypervisor, or utility
   node
 * Maintenance windows or rolling procedures for reboots
 * Package-management access with `apt`
 * Clarity on whether your environment executes untrusted or semi-trusted container
   images

## Steps

**1) Classify hosts by exposure, not by convenience.** The first question is not“
which nodes are easiest to patch?” It is “which nodes run potentially hostile containers
or expose privileged helper paths that make exploitation more realistic?”

**2) Check current kernel and package versions.** Canonical explicitly calls out
kernel, `sudo`, and `util-linux`.

    ```wp-block-code
    uname -r
    dpkg -l 'linux-image*' | grep ^ii
    dpkg -l 'sudo*' | grep ^ii
    dpkg -l util-linux
    ```

**3) Apply updates for everything, not just the easy mitigations.** The advisory
repeatedly recommends a full package upgrade path.

    ```wp-block-code
    sudo apt update && sudo apt upgrade
    ```

If you absolutely must target components separately, Canonical documents that path
too. But the important thing is not to stop after `sudo` or `util-linux` and declare
victory.

**4) Reboot for kernel remediation.** This is the step organizations love to postpone.
It is also the step that turns “packages downloaded” into “kernel actually fixed.”

**5) For clusters, roll deliberately.** On Kubernetes, drain and rotate nodes according
to workload disruption policies. On OpenStack control or compute nodes, follow your
normal availability procedures instead of inventing an outage in the name of security.

**6) Record the versions you landed on.** Canonical publishes fixed versions per
Ubuntu release for affected packages. Put that mapping in your ticket or ops note
so the work is auditable.

## Common pitfalls

 * **Treating userspace mitigations as the finish line.** They reduce risk; they
   do not replace the kernel fix.
 * **Forgetting the reboot.** This is the oldest Linux patching mistake and still
   somehow fashionable.
 * **Ignoring container-specific risk.** Cluster nodes that execute untrusted images
   deserve earlier scheduling.
 * **Skipping version evidence.** “We patched it” is weaker than “we landed on these
   fixed package versions on these hosts.”

## Verify

 * Confirm running kernel versions match the fixed release table relevant to your
   Ubuntu version.
 * Confirm updated `sudo` and `util-linux` package versions where Canonical lists
   mitigations.
 * Verify reboots completed on the hosts that received kernel updates.
 * Review whether any nodes that run less-trusted container workloads were left 
   outside the maintenance window.

Security advisories are cheap. Security runbooks are the real asset. Canonical handed
operators most of the ingredients here. The part that matters now is whether cluster
teams actually turn them into a patch-and-reboot sequence with evidence attached.

---

## Sources

 * [Ubuntu blog: AppArmor vulnerability fixes available](https://ubuntu.com/blog/apparmor-vulnerability-fixes-available)
 * [Ubuntu vulnerability knowledge base: CrackArmor](https://ubuntu.com/security/vulnerabilities/crackarmor)
 * [Qualys advisory: CrackArmor](https://www.qualys.com/2026/03/10/crack-armor.txt)