← All rules
SOCLE-CLD-FSP-095// File ownershiplowfilesystem state

Verify User Who Owns System.map Files

Ensures the /boot directory (which holds System.map and the kernel) is owned by root (uid 0).

Checked against a path’s metadata, mode, owner, group, SUID/SGID.

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 (under /boot) map kernel symbols to addresses and exist mainly for debugging and profiling. Exposed to an attacker, they reveal the exact kernel layout, easing the development of reliable exploits (e.g. defeating KASLR or locating functions for a rootkit). The /boot directory also holds the kernel, initramfs and bootloader config. If owned by a non-root user, these can be read for reconnaissance or modified to compromise the boot chain. Keeping /boot owned by root (uid 0) restricts this sensitive material to the superuser.

What Pavois checks

Pavois asserts that the live directory /boot has owner uid 0, skipped via only_if if it is absent. It reads the effective owner from the filesystem (stat), so a manual chown on boot material is caught even when no config-management tool reports drift.

describe command("find /boot -maxdepth 1 -name 'System.map-*' ! -user root 2>/dev/null") do
  its('stdout.strip') { should eq '' }
end

How to verify it is applied

Run stat -c '%U %u' /boot. Expected output: root 0. To cover the System.map files specifically, run find /boot -name 'System.map*' -not -user root, it should print nothing.

Inspect & investigate

Ownership has no continuous log; query it with stat /boot. If /boot is watched by auditd (auditctl -w /boot -p wa), ownership or content changes appear in /var/log/audit/audit.log, grep the raw log directly, e.g. grep System.map /var/log/audit/audit.log.

Remediation

No automated harden plan is defined, so apply it manually: chown root:root /boot and, for the symbol maps, chown root:root /boot/System.map*.

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

commandfind /boot -maxdepth 1 -name 'System.map-*' -exec chown root {} + 2>/dev/null; true
namesystemmap-user
not_iftest -z "$(find /boot -maxdepth 1 -name 'System.map-*' ! -user root 2>/dev/null)"
resourceexec
pavois harden plan local

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

Impact & precautions

A non-root owner of /boot can read kernel symbol layout (aiding exploit development) or tamper with the boot chain. Restoring root ownership is safe and does not affect a running system. Precaution: when correcting ownership, do not loosen permissions, System.map files and the kernel image should remain readable only by root (mode 0600/0644 per baseline) so the symbol layout is not disclosed; avoid chown -R onto a separately mounted EFI partition (/boot/efi is typically VFAT and owner-agnostic).

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