Verify that Shared Library Files Have Root Ownership
Ensure every file under the shared library directory /lib is owned by root (UID 0).
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
Files in the shared library directories are loaded into the address space of processes (including privileged ones) and of the kernel itself at runtime. If a non-root user owns one, they can overwrite it and inject code that runs with the privileges of every process that loads the library, root ownership is essential to protect system integrity.
What Pavois checks
Pavois runs find -P /lib -type f ! -user 0 and expects no output, any file not owned by UID 0 is a finding. It enumerates the actual on-disk inodes (the effective ownership the loader sees), not a package manifest, so files added or re-owned after install are caught.
only_if { command('test -d /lib').exit_status.zero? }
describe command('timeout 60 find -P /lib -type f ! -user 0 -print -quit 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 -P /lib -type f ! -user 0, it should print nothing. Any line printed is a non-root-owned library file that must be fixed.
Inspect & investigate
Confirm package-provided ownership with dpkg -V (Debian/Ubuntu) or rpm -Va (RHEL/Fedora), which flag ownership/permission drift. List offending files with find -P /lib -type f ! -user 0 -printf '%u %p\n'.
Remediation
No automated remediation for this rule, apply it manually following the standard.
Impact & precautions
What can break: very little, chown root on library files only removes non-standard ownership and rarely affects function. The real risk is masking a problem: a non-root-owned library often signals a compromised package or a misbehaving installer, so investigate the cause before re-owning. Precautions: review each offending file first; if it came from a third-party package, reinstall that package rather than just changing ownership, so permissions and content are both restored.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| NIST | AC-6(1), CM-5(6), CM-5(6).1, CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| DISA STIG | UBTU-22-232070, UBTU-24-300007 | direct | per OS STIG release | 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.