← All rules
SOCLE-CLD-FSP-162// File permissionslowpersistent config

Verify Permissions on System.map Files

Ensures /boot (which holds the System.map kernel symbol files) is not readable, writable or executable by group or other.

Checked against the content of a persistent configuration file, the source of truth that survives reboots.

A pass proves? running now✓ on disk✓ survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 1 standard

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

System.map files map kernel symbol names to memory addresses and are used for debugging and profiling the kernel. Disclosing them hands an attacker the exact addresses of kernel functions and structures, which defeats KASLR and makes kernel exploits far more reliable. Restricting access to root (no read for group/other) keeps this sensitive layout secret.

What Pavois checks

Pavois checks the effective inode permissions of /boot, where the kernel's System.map-* files live, asserting no access for group/other and no setuid/setgid/sticky bits. Reading the live mode (not a packaging record) catches drift introduced by manual chmod, bad images, or post-install scripts that a file-based manifest would miss.

describe command("find /boot -maxdepth 1 -name 'System.map-*' -perm /077 2>/dev/null") do
  its('exit_status') { should_not cmp 124 }
  its('stdout.strip') { should eq '' }
end

How to verify it is applied

Run stat -c '%U %G %a' /boot. Expected: owner/group root with a mode like 700 (or 0700), i.e. no read/write/execute bits for group or other and none of setuid/setgid/sticky set.

Inspect & investigate

Permission drift on boot artifacts is reported by rpm -V kernel (RHEL/Alma) or by comparing against package metadata on Debian/Ubuntu. Mount and access details for /boot can be inspected with findmnt /boot.

Remediation

No automated remediation ships for this rule. Tighten the directory manually with chmod 700 /boot && chown root:root /boot (or restrict the individual System.map-* files with chmod 600).

Pavois applies this with its own harden engine, the plan below, not a shell script:

commandfind /boot -maxdepth 1 -name 'System.map-*' -exec chmod 0600 {} + 2>/dev/null; true
namesystemmap-perms
not_iftest -z "$(find /boot -maxdepth 1 -name 'System.map-*' -perm /077 2>/dev/null)"
resourceexec
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

Leaving System.map world-readable is an information-disclosure risk that strengthens kernel exploits, but the severity is low. Tightening /boot is safe on most systems. Caution: if /boot is a separate mount or EFI partition, or if a non-root boot/update tool needs to read it, an over-restrictive mode can break bootloader updates (e.g. grub-mkconfig, update-grub), verify those still run as root after applying.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R29direct2.0high

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.

Sources & references