CVE-2022-27650: crun/Moby started containers with a non-empty inheritable capability set
Scope: audit · README · COMPARISON · docs/RESEARCH
CVSS 7.5. Fixed in crun 1.4.4; related Moby advisory GHSA-wr4f-w546-m398.
Source
Relevance to doos
crun (and, separately, Moby) could start a container process with inheritable
capabilities still set in its capability set, rather than cleared. A program inside the
container carrying file capabilities (cap_setuid+ep and similar) can raise an
inheritable capability into its permitted set across execve, turning a leftover
inheritable bit into a real privilege gain. doos drops to a fixed capability bounding
set in Hardening::apply() before exec; the inheritable set specifically is the thing
this bug class is about, and it is worth confirming directly rather than only checking
the effective set (which is what the README and docs/RESEARCH.md already measure via
CapEff).
What the check does
Attaches a container with default hardening and reads /proc/self/status's CapInh
line. Anything other than all-zero is FAIL.
Caveats
Only checks default hardening; --hardening relaxed is documented as removing capability
restrictions entirely and is out of scope here, same as the other hardening-dependent
checks in this audit.
Run: make test in this directory, or make -C audit test from the repo root.