Enable checks on credential management
Ensures the running kernel is built with CONFIG_DEBUG_CREDENTIALS=y (where the symbol exists), adding sanity checks that detect tampering with credential (struct cred) structures.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
CONFIG_DEBUG_CREDENTIALS=y adds runtime sanity checks and validation to the kernel's struct cred objects, which hold a task's UID/GID and capabilities. Many privilege-escalation exploits work by corrupting or overwriting these credential structures to grant themselves root. The extra validation detects such tampering (mismatched magic values, bad reference counts) and triggers a BUG(), turning a silent credential overwrite into an immediate, visible failure rather than a successful escalation. Note: this option was removed from the mainline kernel around v6.3 because the checks became always-on; on those kernels the symbol is simply absent.
What Pavois checks
Pavois reads the build-time config of the running kernel via /boot/config-$(uname -r) (fallback /proc/config.gz) and asserts CONFIG_DEBUG_CREDENTIALS=y. Keying on uname -r matches the exact booted image, more reliable than reading a random /boot/config-*. On kernels ≥ 6.3 the symbol no longer exists (checks are unconditional), so a missing line may be expected rather than a real gap.
describe command("C=/boot/config-$(uname -r); if [ -r \"$C\" ]; then cat \"$C\"; elif zcat /proc/config.gz 2>/dev/null | head -1 | grep -q .; then zcat /proc/config.gz; else echo PAVOIS_NO_KERNEL_CONFIG; fi | grep -E '^(CONFIG_DEBUG_CREDENTIALS=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_DEBUG_CREDENTIALS=y$/) }
endHow to verify it is applied
Run grep -h '^CONFIG_DEBUG_CREDENTIALS=' /boot/config-$(uname -r) (or zcat /proc/config.gz | grep DEBUG_CREDENTIALS). Expected: CONFIG_DEBUG_CREDENTIALS=y, or no symbol at all on kernels ≥ 6.3 (uname -r).
Inspect & investigate
Static kernel build option, no dedicated log. Inspect with zcat /proc/config.gz | grep DEBUG_CREDENTIALS or grep DEBUG_CREDENTIALS /boot/config-$(uname -r). If a credential check fails at runtime, the resulting BUG()/oops appears in dmesg and journalctl -k.
Remediation
No automated remediation is shipped: this is a kernel compile-time option. Apply it by booting a kernel built with CONFIG_DEBUG_CREDENTIALS=y (a hardened kernel), or rebuild the kernel. On kernels ≥ 6.3 no action is needed, the checks are always compiled in. pavois harden apply cannot change it.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| resource | kernel_build |
|---|
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk if disabled (on kernels that still have the symbol): corruption or overwrite of credential structures, a common privilege-escalation primitive, goes undetected and can succeed silently.
Precautions before changing it: the checks add a small runtime overhead but no functional risk. Changing kernels requires a reboot; keep the previous kernel in GRUB as a fallback and validate boot on a console. Do not treat a missing symbol on recent kernels (≥ 6.3) as a regression.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R16 | direct | 2.0 | high |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.