Disallow magic SysRq key
Sets kernel.sysrq = 0 to disable the magic SysRq key and its direct-to-kernel commands.
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
The magic SysRq key sends commands directly to the running kernel, bypassing normal access controls. It can dump system and process state (potentially leaking sensitive information) and can immediately reboot, halt, kill all processes or sync/remount filesystems, disrupting availability. Anyone with physical or serial-console access (and in some setups via /proc/sysrq-trigger) could abuse it. Setting kernel.sysrq = 0 disables these functions.
What Pavois checks
Pavois reads the live kernel value with kernel_parameter('kernel.sysrq') (equivalent to sysctl kernel.sysrq), not a /etc/sysctl.d/*.conf line. The value is a bitmask: distributions often ship a non-zero default and a later drop-in may re-enable specific functions, so a config file alone does not reveal what is currently allowed. Only the effective parameter shows the kernel's actual SysRq policy.
describe kernel_parameter('kernel.sysrq') do
its('value') { should cmp 0 }
end
describe command("grep -hsE '^[[:space:]]*kernel.sysrq[[:space:]]*=[[:space:]]*0([[:space:]]|$)' /etc/sysctl.conf /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf 2>/dev/null") do
its('stdout') { should match(/\S/) }
endHow to verify it is applied
Run sysctl kernel.sysrq. Expected output:
kernel.sysrq = 0
Inspect & investigate
No dedicated log line for the setting itself. Confirm with sysctl kernel.sysrq. Whenever a SysRq command is actually invoked, the kernel logs sysrq: ... in dmesg/journalctl -k; with the value at 0 those invocations are rejected.
Remediation
Pavois's harden plan uses the sysctl resource to set kernel.sysrq = 0, persists it in a Pavois-managed drop-in under /etc/sysctl.d/, and applies it live (no reboot). Apply it with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| key | kernel.sysrq |
|---|---|
| resource | sysctl |
| value | 0 |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk if not applied: an attacker with console/serial access (or /proc/sysrq-trigger access) can halt, reboot or dump the machine, harming availability and confidentiality.
Precautions before applying:
- Disabling SysRq removes a valuable emergency recovery and debugging tool. The safe-reboot sequence (
Alt+SysRq+R-E-I-S-U-B), live crash triggers, and on-demand stack dumps will no longer work. If your operations rely on SysRq for recovery on headless or hung systems, consider a restrictive bitmask instead of0, or ensure alternative out-of-band recovery (IPMI/iLO) is in place. - No application or boot lockout risk; the change is fully reversible at runtime.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R9 | 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.