How LinPEAS audits file permissions

Where it appears in the output#

These checks are in the Files with Interesting Permissions section (interesting_perms_files), with more file findings in Other Interesting Files (interesting_files). LinPEAS hunts world-writable files, files with POSIX ACLs, ld.so configuration issues, writable files owned by root that get executed with privileges, and sensitive files (like /etc/passwd and /etc/shadow) with wrong permissions.

╔══════════╣ Writable root-owned executables I can modify
/usr/local/bin/maintenance (owner root, writable by you)
╔══════════╣ Files with ACLs
/etc/some.conf  user:you:rw-
╔══════════╣ /etc/passwd and /etc/shadow permissions
-rw-rw-rw- /etc/passwd   <-- world-writable!

How to read a permission finding#

Reproduce the checks manually#

find / -xdev -type f -perm -0002 ! -type l 2>/dev/null   # world-writable files
find / -xdev -type d -perm -0002 2>/dev/null            # world-writable dirs
ls -la /etc/passwd /etc/shadow                           # the two critical files
getfacl -p /etc/passwd 2>/dev/null                       # ACLs, not just mode bits
cat /etc/ld.so.conf; cat /etc/ld.so.conf.d/* 2>/dev/null # library search config

Lab walkthrough: writable /etc/passwd (authorised lab only)#

A world-writable /etc/passwd is the classic textbook case. In a lab VM where LinPEAS flags it, the proof-of-concept is:

1. 1

2. 2

3. 3

4. 4

Readable /etc/shadow: what it means#

If /etc/shadow is readable by your user, every password hash on the system is exposed. The authorised workflow is to copy the hash off the target and attack it offline on your own hardware (e.g. hashcat -m 1800 hash.txt rockyou.txt for SHA-512 crypt), never to run cracking tools on the target itself. A cracked root or sudo-capable password is then used only within scope.

How to fix permission findings (defensive)#

• /etc/passwd must be 644 root:root; /etc/shadow and /etc/gshadow must be 640 root:shadow (or 0).
• Remove world-writable bits from files and directories you own: chmod o-w. Use find / -perm -0002 in your own audits.
• Prefer group ownership + 2770-style modes over world-writable shared dirs; use the sticky bit (1777) only on /tmp-like dirs.
• Audit ACLs with getfacl -R — they override what ls -l suggests.
• Keep ld.so.conf and library directories root-owned; never add writable paths.
• Executables that run privileged must be root-owned and non-writable by others.
• Re-run LinPEAS after hardening to confirm the findings are gone.

ACLs: the permissions ls -l hides#

POSIX Access Control Lists grant per-user or per-group rights that the classic rwxrwxrwx display does not show (only a + hints at them). LinPEAS explicitly enumerates files with ACLs because they are a favourite place for quiet misconfigurations:

ls -l /etc/some.conf        # -rw-r-----+  <- the + means ACLs exist
getfacl -p /etc/some.conf   # show the full ACL
# look for lines like:  user:analyst:rw-   (access you should not have)

• An ACL like user:you:rw- on a root-owned config file is invisible to ls -l but fully usable.
• The mask line caps the effective rights of named users/groups — a tight mask can neuter a sloppy ACL, and vice versa.
• Default ACLs on directories propagate to new files — audit the directory, not just the file.
• Fix: setfacl -b removes all extended ACLs; prefer group modes over per-user ACLs for clarity.

Sticky bit and shared directories#

World-writable directories are normal in exactly one place — /tmp-style scratch space — and only because the sticky bit (t) stops users deleting each other's files:

• drwxrwxrwt /tmp — correct: anyone can create, only owners can delete their own.
• drwxrwxrwx /opt/shared — wrong: anyone can delete or replace anyone's files — including scripts a privileged job might pick up.
• LinPEAS flags world-writable directories; check each for the sticky bit and for what consumes files from it.
• Fix: chmod 1777 /tmp for scratch; for shared project dirs prefer group ownership (2770) over world-writable.

The find commands worth memorising#

These five cover most of what LinPEAS checks in this area — useful when you cannot run the script at all:

# world-writable files (excluding symlinks) and directories
find / -xdev -type f -perm -0002 ! -type l 2>/dev/null
find / -xdev -type d -perm -0002 2>/dev/null
# files owned by root but writable by you
find / -xdev -user root -perm -002 -type f 2>/dev/null
# SUID/SGID in one pass
find / -xdev -type f \( -perm -4000 -o -perm -2000 \) 2>/dev/null
# recently modified system files (possible tampering)
find /etc /bin /usr/bin -xdev -mtime -2 2>/dev/null

• -xdev keeps the search on one filesystem — faster and avoids /proc noise.
• Always append 2>/dev/null; permission errors otherwise bury the results.
• Pipe through ls -ld or -exec ls -l {} \; when you need owners, not just paths.

Umask: the quiet default#

Many permission findings trace back to a permissive umask. A umask of 022 is standard; 002 or 000 in a service or user profile means every file it creates is group- or world-writable by default — a steady source of the findings LinPEAS reports. Check /etc/profile, /etc/bashrc and systemd unit UMask= directives when the same class of finding keeps reappearing after you fix instances.

Concepts: Linux file permissions, why UID 0 is root. Related checks: SUID, credentials.