Verify that All World-Writable Directories Have Sticky Bits Set
Ensure every world-writable directory on a local filesystem also has the sticky bit set, so users can only delete or rename files they own.
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
On a world-writable directory without the sticky bit, any user can delete, rename or replace files created by other users. This enables file-swap and symlink attacks, log/temp-file destruction and denial of service. The sticky bit (+t, mode 01000) restricts deletion to the file's owner, which is why shared spaces like /tmp and /var/tmp set it. Any other world-writable directory lacking it is a likely misconfiguration.
What Pavois checks
Pavois runs find / -xdev -type d -perm -0002 ! -perm -1000 and asserts the output is empty, i.e. there is no directory that is world-writable yet missing the sticky bit. -xdev stays on the root filesystem to avoid scanning network mounts; the 2>/dev/null and timeout 90 keep the live scan bounded. This walks the actual filesystem state rather than trusting package metadata, so it catches directories created by applications, archives or admins after install.
describe command('timeout 90 find / -xdev -type d -perm -0002 ! -perm -1000 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 / -xdev -type d -perm -0002 ! -perm -1000 2>/dev/null. The expected output is empty (no offending directory). Any path printed is world-writable without the sticky bit and must be fixed.
Inspect & investigate
There is no service log for this filesystem-wide check; the scan command above is the audit. To see who can write where, stat -c '%A %n' <dir>. If you want change detection, an integrity tool (AIDE: aide --check) or an audit watch on the directory (auditctl -w <dir> -p wa) will surface modifications via /var/log/audit/audit.log.
Remediation
No automated harden plan ships for this rule (the offending directories vary per host and some may be intentional), so it must be applied manually: for each path returned, either add the sticky bit with chmod a+t <dir> (if the directory legitimately needs to be shared) or remove world-write with chmod o-w <dir> (preferred when sharing is not required).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | find / -xdev -type d -perm -0002 ! -perm -1000 2>/dev/null # for each: chmod +t <dir> (after confirming it is a shared directory) |
|---|---|
| reason | setting the sticky bit on shared dirs is usually safe but verify each is a real shared dir |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Without the sticky bit, shared directories invite file deletion, symlink/race attacks and tampering. Precautions: review each path before acting, blindly running chmod o-w on an application's shared spool/socket directory can break that application, while adding a+t to a directory that was never meant to be world-writable masks a deeper permission problem. Prefer removing world-write unless the directory's purpose genuinely requires shared write access (like /tmp). Test on a non-production host first when many paths are returned.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R54 | direct | 2.0 | high |
| CIS | 2.2.6, 7.1.11 | direct | per OS, see the benchmark table | high |
| NIST | AC-6(1), CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 2.2.6 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-22-232145, UBTU-24-600150 | 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.