gmsmeghana/Linux-Permissions-Privilege-Escalation

# Linux File Permissions & Privilege Escalation — SetUID, umask & Capability Leaking A deep-dive into **Linux file permission management** and **privilege escalation techniques** including SetUID exploitation, PATH hijacking, and capability leaking. Covers both the mechanics of Linux access controls and how misconfigurations can be exploited to gain elevated privileges. ## Tools & Environment | Tool | Purpose | |------|---------| | Ubuntu Linux | Lab environment | | chmod / chown | Permission management | | umask | Default permission control | | SetUID binaries | Privilege escalation vector | | GCC | Compiling exploit code | ## Part A — Linux File Permissions ### Step 1 — File Ownership & Basic Permissions Created files and directories under multiple user accounts to observe ownership and permission inheritance:    **Ownership analysis:** - `Hello world` — owned by `user1`, group `users` - After `chown` — ownership transferred to `user2`, group `users` ### Step 2 — Directory Permission Analysis Examined permissions across home directories for multiple users:   | Directory | Permissions | Meaning | |-----------|-------------|---------| | `/home/user1` | `drwxr-xr-x` | Owner: full access; Group/Others: read + execute | | `/home/user2` | `drwxrwx---` | Owner + Group: full access; Others: no access | | `/home/test` | `drwxr-xr-x` | Owner: full access; Group/Others: read + execute | ### Step 3 — Cross-User Access Testing Tested whether `user1` could access `user2`'s home directory under different permission settings:      **Findings:** - `user1` could `cd` into `/home/user2` when group permissions allowed it - After `chmod 700 /home/user2`, access was correctly denied - After modifying permissions to `755`, `user1` could list contents and create files ### Step 4 — File Write & Read Permission Testing Tested read/write access between users on shared files:     **Result:** `user1` could not modify `file1` without write permissions. `user2` (the owner) retained full access. ### Step 5 — Symbolic Links Created and analyzed symbolic links — confirming that symlinks inherit the permissions of the target file rather than having their own: lrwxrwxrwx -> /test/temp/hello.txt The actual permissions of `hello.txt` remain `-rw-rw-r--` regardless of the symlink's displayed permissions.    ### Step 6 — umask — Default Permission Control Tested the effect of different `umask` values on newly created files and directories:  | umask | New File Permissions | New Directory Permissions | |-------|---------------------|--------------------------| | `0002` (default) | `664` (rw-rw-r--) | `775` (rwxrwxr-x) | | `0077` (restrictive) | `600` (rw-------) | `700` (rwx------) | | `0000` (open) | `666` (rw-rw-rw-) | `777` (rwxrwxrwx) | **Security risk of `umask 0000`:** All users can read and modify any new file — a critical misconfiguration in multi-user environments. Best practice is `umask 0022` or `0077` for sensitive files.    ## Part B — Privilege Escalation ### Step 1 — SetUID Binaries **SetUID** allows a program to run with the privileges of the file owner rather than the executing user. Key system binaries that require SetUID: | Binary | Why SetUID is needed | |--------|---------------------| | `passwd` | Must write to `/etc/shadow` (root-only) | | `chsh` | Must edit `/etc/passwd` (root-only) | | `su` | Must authenticate against privileged resources | | `sudo` | Must check `/etc/sudoers` for elevated permissions | Without SetUID, none of these operations would be possible for regular users.       **Result:** Bash detects when it is running in a SetUID environment and drops elevated privileges — a built-in protection preventing direct root shell access this way. ### Step 2 — PATH Hijacking via SetUID Exploited a SetUID program that calls `ls` without an absolute path. By modifying the `PATH` variable to point to a malicious binary named `ls` (actually a shell), elevated privileges were obtained:      **Result:** The program executed the malicious `ls` binary instead of the real one, spawning a root shell. This demonstrates why SetUID programs must always use **absolute paths** for system calls.  ### Step 3 — Capability Leaking Analyzed a vulnerable SetUID C program (`hack2.c`) that leaks file descriptor access after dropping privileges:    **Vulnerability explained:** 1. Program opens `/etc/zzz` (root-owned) with read/write access 2. Drops root privileges using `setuid(getuid())` 3. Forks a child process — which **inherits the open file descriptor** 4. The child process (now running as a normal user) writes `"Malicious Data"` to `/etc/zzz` **Root cause:** The program failed to close the file descriptor before relinquishing privileges. The child process retains access to the privileged resource even after the parent drops its elevated rights — a classic **capability leaking** vulnerability. ## Key Takeaways - File permission misconfigurations are one of the most common Linux privilege escalation vectors - SetUID binaries must always use absolute paths to prevent PATH hijacking attacks - `umask 0000` is a critical security risk — always use restrictive defaults - File descriptors must be explicitly closed before dropping privileges to prevent capability leaking - Understanding how Linux access controls work is fundamental to both system hardening and penetration testing ## Disclaimer All privilege escalation techniques were performed in a controlled, isolated lab environment. These techniques must only be used on systems you own or have explicit authorization to test.