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

Ensure no world-writable files exist

Ensures no file on a local filesystem is world-writable (the o+w / 0002 permission bit set).

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 4 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

A world-writable file (o+w, the 0002 permission bit) can be modified by any user on the system. An attacker or a compromised low-privilege account can overwrite such a file to inject malicious content, tamper with data or stage a privilege-escalation payload. Almost all legitimate sharing needs can be met with user and group permissions, so world-writable files are gratuitous risk and should not exist on local filesystems.

What Pavois checks

Pavois runs find / -xdev -type f -perm -0002 and expects empty output, any path returned is a world-writable file. The -xdev flag keeps the scan on the local filesystem (skipping mounted network or pseudo filesystems). Auditing actual inode permissions catches files created at runtime, extracted from archives or chmod-ed by an operator, which a package-manifest or config-file audit cannot detect.

describe command('timeout 90 find / -xdev -type f -perm -0002 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 / -xdev -type f -perm -0002

Expected output: nothing (empty). For each printed path, inspect with ls -l <file> and remove the world-write bit with chmod o-w <file> once you have confirmed it is safe.

Inspect & investigate

List all offenders with their mode using find / -xdev -type f -perm -0002 -printf '%M %p\n'. There is no dedicated system log; permission changes are recorded only if an auditd watch on chmod/fchmodat is configured. Re-run the find after fixing to confirm an empty result.

Remediation

No automated harden plan is defined for this rule, so it must be applied manually. World-writable files are too case-specific for a blind sweep: review each one and remove the bit with chmod o-w <file>, or relocate genuinely shared data behind proper group permissions or a sticky-bit directory. Auto-fixing every match could break an application that expects a writable drop path.

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

command# List world-writable files (excluding the sticky-bit dirs), then fix each after review: find / -xdev -type f -perm -0002 2>/dev/null # for each legitimate-to-fix: chmod o-w <file>
reasonauto-chmod over a find risks breaking apps that rely on a world-writable path, review each
resourcemanual
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: any user can alter the file's contents, corrupting data, planting code, or hijacking a script that a privileged process later executes. Before fixing: some applications legitimately rely on a world-writable drop file or socket path; removing o+w from those will break them. Identify the owning application of each match first; prefer a sticky-bit shared directory (mode 1777, like /tmp) over a world-writable file. Remove the bit file by file, never with a recursive chmod across /.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R54direct2.0high
CIS2.2.6, 7.1.11directper OS, see the benchmark tablehigh
NISTAC-6(1), CM-6(a)supporting800-53 Rev 5 · 800-171 Rev 2 (pinned)medium
PCI DSS2.2.6supporting4.0.1medium

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