Prefer to use a 64-bit Operating System when supported
Requires the system to run a 64-bit kernel architecture (x86_64, aarch64, amd64, s390x) rather than a legacy 32-bit one.
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
A 64-bit operating system materially improves the effectiveness of two key exploit mitigations. The much larger address space makes Address Space Layout Randomization (ASLR) far harder to brute-force, and 64-bit platforms guarantee the No eXecute / Execute Disable (NX/XD) bits that block code execution from data pages, defeating many memory-corruption attacks. A 32-bit OS weakens both, making exploitation more practical.
What Pavois checks
Pavois reads the running kernel architecture with uname -m, the architecture the machine is actually booted on. This reflects the live state, which is what matters for exploit mitigations; inspecting package metadata or installer files could report a different or planned architecture, not the one in effect.
describe command('uname -m | grep -qE \'x86_64|aarch64|amd64|s390x\' && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
Run uname -m. The expected output is a 64-bit architecture such as x86_64, aarch64, amd64 or s390x. A value like i686 or i386 indicates a non-compliant 32-bit system.
Inspect & investigate
There is no event log for architecture. Confirm at any time with uname -m, or inspect boot details with dmesg | head and cat /proc/cpuinfo (the lm CPU flag indicates 64-bit capability).
Remediation
No automated harden plan exists for this rule, and it cannot be fixed in place: switching from 32-bit to 64-bit requires reinstalling the operating system with a 64-bit image on 64-bit-capable hardware. It must be addressed manually during provisioning.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | uname -m # if not x86_64/aarch64, a reinstall is required (audit-only finding) |
|---|---|
| reason | the OS architecture cannot be changed in place, reinstall as 64-bit if needed |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
This rule is informational on modern hardware, virtually all current servers and cloud images are already 64-bit. A non-compliant result almost always means a legacy or embedded host. Remediation is not a configuration change but a full reinstall, so plan it as a migration: back up data, validate that all required software has 64-bit packages, and rebuild rather than attempt an in-place conversion.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R1 | 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.