Verify that system commands directories have root as a group owner
Ensure every directory under the system command paths (/bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin) is owned by root, so only root can manage the binaries they hold.
Checked against a path’s metadata, mode, owner, group, SUID/SGID.
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
These directories hold the system's executables and privileged programs. If a directory is owned by a non-root account, that account can add, replace or remove binaries, letting it inject a trojaned command that other users (including root) will later run, bypassing change-management and escalating privilege. Software libraries and interpreted-language binaries here run with elevated rights, so only root must control these paths.
What Pavois checks
Pavois runs find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type d ! -user root and asserts the output is empty, i.e. no directory in the command paths has a non-root owner. 2>/dev/null and timeout 90 keep the live scan bounded. This walks the actual filesystem ownership instead of trusting package metadata, so it catches directories whose owner drifted after a manual chown, a sloppy installer or an unpacked archive. (Note: the check tests the owner via ! -user root; the title's wording is preserved for compatibility.)
describe command('timeout 90 find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type d ! -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 '' }
endHow to verify it is applied
Run find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type d ! -user root 2>/dev/null. The expected output is empty. Any path printed is a command directory not owned by root and must be corrected.
Inspect & investigate
There is no service log for this filesystem-wide check; the scan command above is the audit. Inspect ownership with stat -c '%U:%G %n' <dir> and ls -ld <dir>. To detect future ownership changes, use an integrity tool (AIDE: aide --check) or an audit watch (auditctl -w /usr/bin -p wa) and review /var/log/audit/audit.log.
Remediation
No automated harden plan ships for this rule, so it must be applied manually: for each path returned, restore root ownership with chown root <dir> (use chown root:root <dir> to also reset the group). Investigate why a system directory changed owner before fixing it, in case it indicates compromise.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | # Review ownership/permissions of system command directories (e.g. /bin /sbin /usr/bin /usr/sbin): find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -xdev \( -perm -0002 -o ! -user root \) 2>/dev/null # fix each after review: chown root <path> ; chmod o-w <path> |
|---|---|
| reason | tightening perms on system command dirs can break packaged tooling, review |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A non-root-owned command directory is a direct privilege-escalation vector and may signal compromise. Precautions: chown root on these directories is low-risk and matches the package-manager default, but a directory under /usr/local may have been intentionally delegated to a service account, confirm that before reverting, or the owning service may lose the ability to update its own binaries. Restoring ownership does not change permissions, so it will not break execution for normal users.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | high |
| NIST | CM-5(6), CM-5(6).1 | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
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.