Verify that Shared Library Files Have Restrictive Permissions
Ensures the shared-library directory /lib is not writable by group or other, preventing injection of malicious libraries into privileged processes.
Checked against the content of a persistent configuration file, the source of truth that survives reboots.
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 (such as /lib) are loaded into the address space of processes, including privileged ones, and sometimes of the kernel itself at runtime. If the library directory is writable by group or other, an unprivileged user could replace or add a .so that is then loaded by a root process, achieving arbitrary code execution as root. Restrictive permissions (no write for group or other) are necessary to protect the integrity of every program that links against these libraries.
What Pavois checks
Pavois reads the effective directory mode of /lib and asserts no write bit for group or other. Guarded by only_if { file('/lib').exist? }. On modern distros /lib is typically a symlink into /usr/lib; checking the live inode follows the path the dynamic loader actually uses, so the assertion reflects what ld.so will trust at runtime rather than a packaging assumption.
only_if { file('/lib').exist? }
describe file('/lib') do
it { should_not be_writable.by('group') }
it { should_not be_writable.by('other') }
endHow to verify it is applied
Run stat -c '%a %U %G' /lib (and, since it is usually a symlink, stat -c '%a %U %G' /usr/lib). The expected output is 755 root root or stricter: no write bit for group or other.
Inspect & investigate
stat /lib and find /lib /usr/lib -perm /022 -type d reveal any group/other-writable directories. Package integrity of the library files can be checked with dpkg --verify (Debian/Ubuntu) or rpm -Va (RHEL family). Changes appear in /var/log/audit/audit.log if these paths are watched.
Remediation
No automated harden plan is defined for this rule yet, so apply it manually: remove group/other write with chmod -R go-w /lib /usr/lib and ensure ownership is root (chown -R root:root /usr/lib). Apply carefully, see the impact note.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0755 |
|---|---|
| path | /lib |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A group- or world-writable library directory is a direct path to root code execution: an attacker plants a malicious .so that a privileged process loads. Precautions: never remove read/execute (traverse) bits from /lib, only the write bits, or you will break dynamic linking for the entire system and may render it unbootable. Some third-party software installs libraries with loose permissions; before a recursive chmod, audit with find /lib /usr/lib -perm /022 so you understand what will change, and avoid altering ownership of vendor directories that a non-root service legitimately manages.
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-232020, UBTU-24-300006 | 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.