← All rules
SOCLE-CLD-FSP-185// Filesystem (scan)mediumfilesystem state

Verify that system executables have root ownership

Ensures every executable in the system command directories (/bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin) is owned by root.

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 3 standards

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 binaries are executed by privileged users and by system services, often with escalated rights. If an executable in a system command directory is owned by a non-root user, that user can overwrite the binary and have their code run with the privileges of the next caller, a textbook privilege-escalation and persistence vector. Restricting ownership to root ensures these programs cannot be co-opted.

What Pavois checks

Pavois runs find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type f ! -user root and expects empty output, any returned path is a binary owned by a non-root user. Scanning the real on-disk files (not the package database) catches manually installed tools, scripts dropped into /usr/local/bin and binaries whose owner was changed after install, which a package-manifest audit would never report.

describe command('timeout 90 find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type f ! -user root 2>/dev/null') do
  its('exit_status') { should_not cmp 124 }  # timeout killed the scan: no evidence, not a pass
  its('stdout.strip') { should eq '' }
end

How to verify it is applied

Run the scan manually:

find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type f ! -user root

Expected output: nothing (empty). Inspect any printed path with ls -l <file>.

Inspect & investigate

List offenders and their owner with find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type f ! -user root -printf '%u %p\n'. On RPM systems cross-check with rpm -Vf <file> (the U flag flags an ownership drift); a non-root owner on a packaged binary almost always signals a local modification worth investigating.

Remediation

No automated harden plan is defined for this rule, so it must be applied manually. After confirming the file should legitimately belong to root, reset ownership with chown root <file>. Because a non-root-owned system binary can indicate a compromise, investigate the cause before changing it.

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

commandfind /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type f \( ! -user root -o ! -group root \) -exec chown root:root {} + 2>/dev/null; true
namefix-bindir-ownership
not_iftest -z "$(find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type f \( ! -user root -o ! -group root \) 2>/dev/null | head -1)"
resourceexec
pavois harden plan local

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

Impact & precautions

Risk if left as-is: a non-root-owned system binary lets its owner replace it and hijack any privileged process that later runs it. Before fixing: a very small number of third-party packages legitimately install helpers owned by a dedicated service account; running chown root on those could break the tool. Change ownership one file at a time, verify the binary's integrity (rpm -Vf or a trusted checksum) first, and never run a recursive chown over /usr blindly.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R50direct2.0high
NISTAC-6(1), CM-5(6), CM-5(6).1, CM-6(a)supporting800-53 Rev 5 · 800-171 Rev 2 (pinned)medium
DISA STIGUBTU-22-232050, UBTU-24-300012directper OS STIG releasehigh

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