File & Process Permissions — The Gateway to Exploits

⚠️ A quick safety note

This post explains how Linux permissions and special bits work and how misconfigurations can be abused — for educational and defensive purposes only. Always practice on your own lab machines (VMs) and never test these techniques on systems you don’t own or have explicit permission to test.

🧩 Why permissions matter

Linux enforces access control through users, groups, and permission bits. Misconfigured permissions are one of the most common vectors attackers use to escalate privileges or move laterally. If you understand permissions deeply, you can both exploit intentionally vulnerable labs for learning and harden real systems to stop attackers.

🧾 1 — The basics: users, groups, and the permission model

Every file and directory has:

Owner (user) — who owns the file
Group — a group associated with the file
Permissions — what owner, group, and others can do

The three permission types:

r — read
w — write
x — execute

ls -l shows permissions in a human-readable line such as:

-rwxr-xr-- 1 alice staff 1024 Aug 10 file.txt

Breakdown:

- file type (directory d, link l, etc.)
rwx owner permissions
r-x group permissions
r-- others permissions

🔢 2 — Numeric (octal) permissions in a nutshell

Permissions are often represented as a 3-digit octal number:

r = 4
w = 2
x = 1

Add them per class:

7 = rwx (4+2+1)
6 = rw- (4+2)
5 = r-x (4+1)
4 = r--

Examples:

chmod 755 file → owner rwx, group r-x, others r-x.
chmod 644 file → owner rw-, group r--, others r--.

These are basic sysadmin skills — every hacker must know them.

🧨 3 — Special bits: SUID, SGID, and the sticky bit (what they do and why they matter)

SUID (Set-user-ID)

When the SUID bit is set on an executable, that program runs with the owner’s privileges instead of the calling user’s.
Represented as an s in the owner execute position (e.g., -rwsr-xr-x).

Why it matters: If an SUID binary is writable by an attacker or is vulnerable, it can be used to perform actions as the owner — sometimes even root. That’s why SUID root binaries require strict control.

SGID (Set-group-ID)

When set on an executable, the program runs with the group privileges of the file.
When set on a directory, new files created inside inherit the directory’s group.

Sticky bit

Common on shared directories like /tmp.
Prevents users from deleting or renaming files they don’t own within that directory.
Shown as a t in the others execute position (e.g., drwxrwxrwt).

🔎 4 — Common permission misconfigurations attackers look for (conceptual)

These are patterns you should be able to spot and fix:

World-writable files/directories (chmod 777) — unwanted write access for any user.
SUID/SGID binaries owned by root but writable by non-root — dangerous combination.
Sensitive files readable by others — e.g., backups or config files containing secrets.
Improper /tmp usage — insecure temp files or predictable filenames.
Services running as root unnecessarily — increase attack surface if exploited.

Note: I’m describing patterns, not giving exploit steps. Use this knowledge to secure systems and to practice defensive detection in lab environments.

🛠️ 5 — How to audit permissions safely (lab-friendly checks)

When you’re in a controlled lab, these safe checks help you find misconfigurations:

ls -la — quickly inspect file modes and owners.
find / -perm -4000 -type f 2>/dev/null — (safe for a lab) lists SUID binaries so you can study them (don’t run on systems you don’t own).
find / -writable -type d 2>/dev/null — find world-writable directories in a lab environment.

Important: Only run system-wide scans on machines you own or are explicitly authorized to test.

🛡️ 6 — Remediation: how to fix common issues (defensive guidance)

Remove unnecessary SUID/SGID bits from binaries that don’t need them.
Harden file modes: avoid 777 unless absolutely required; use the principle of least privilege.
Fix ownership: ensure files are owned by the correct user and group (chown).
Use secure tmp directories: mount /tmp with noexec,nosuid where possible and appropriate.
Audit services: run daemons as unprivileged users instead of root.
Monitor changes: file integrity monitoring (e.g., AIDE, tripwire) to detect unauthorized permission changes.

🧪 7 — Safe practice exercises (do these in your VM lab)

Inspect permissions
- Create a small lab VM (Kali or Ubuntu) and practice ls -l, stat, and octal chmod changes on dummy files.
SUID/SGID exploration (controlled)
- List SUID binaries in your lab and research what they do. Don’t modify production binaries.
Fix a misconfigured directory
- Make a test directory world-writable, then tighten permissions and verify behavior.
Service hardening
- Install a service in a VM and configure it to run as an unprivileged user.

Always snapshot your VM before experiments so you can revert to a clean state.

🧠 8 — How this ties into privilege escalation

Permissions are often the first thing a post-exploitation actor investigates. Understanding ownership, special bits, and misconfigurations helps you:

Recognize escalation opportunities in lab scenarios
Write defensive checks and alerts in production
Harden systems to reduce real-world risk

🎯 Coming Up Next

Part 5: Users, Groups & Root — Understanding Access Control
We’ll go deeper into user management, sudo, and safe practices for administering Linux systems.

💬 Got Questions?

Drop them in the comments or join our community on Discord for exclusive hacking tips and resources.

Don’t worry — mastery comes with practice.
Just open your terminal and hack your brain into CLI mode daily.

Let’s keep building. 💻⚔️