Permissions & Ownership

Linux permissions are where security theory meets harsh reality: a single misconfigured bit on a file can let an unprivileged user become root. Understanding permissions is non-negotiable for both attackers looking to escalate and defenders trying to prevent it.

The Permission Model

Every file and directory in Linux has three sets of permissions for three groups:

-rwxr-xr-x 1 alice developers 4096 May 27 09:00 script.sh
 ^^^------  (user/owner permissions)
    ^^^---  (group permissions)
       ^^^  (other/world permissions)

Each set has three bits:

• r - read (4)
• w - write (2)
• x - execute (1)
• - - permission not granted (0)

The first character indicates the file type:

• - - regular file
• d - directory
• l - symbolic link
• c - character device
• b - block device

Reading Permission Strings

Let's decode each:

For directories, the bits mean something slightly different:

• r - can list the directory contents (ls)
• w - can create, delete, and rename files inside the directory
• x - can enter the directory and access files inside (traverse)

You can have a directory that's executable but not readable - you can cd into it and access files if you know their names, but you can't ls to see what's there.

Octal Notation

Permissions are often expressed as octal numbers. Each permission group (user, group, other) is a 3-bit number:

r=4, w=2, x=1
 
rwx = 4+2+1 = 7
rw- = 4+2+0 = 6
r-x = 4+0+1 = 5
r-- = 4+0+0 = 4
--- = 0+0+0 = 0

So chmod 755 means:

• User: 7 (rwx)
• Group: 5 (r-x)
• Other: 5 (r-x)

Common octal patterns and their uses:

chmod - Changing Permissions

chmod changes permissions. You can use octal notation or symbolic notation.

Octal (Absolute)

Sets all permissions at once:

chmod 755 script.sh      # rwxr-xr-x
chmod 644 config.txt     # rw-r--r--
chmod 600 private.key    # rw-------
chmod 700 myfolder/      # rwx------
chmod -R 755 webroot/    # recursive: set 755 on all files in webroot/

Symbolic (Relative)

Adds or removes specific permissions without changing others:

chmod +x script.sh          # add execute for user, group, other
chmod u+x script.sh         # add execute for user only
chmod g-w file.txt          # remove write from group
chmod o-r private.txt       # remove read from others
chmod u+rw,g-w,o-rw file    # complex: multiple changes at once
chmod a+r public.html       # add read for all (a = all = ugo)

The format is [who][operator][permission]:

• Who: u (user/owner), g (group), o (other), a (all)
• Operator: + (add), - (remove), = (set exactly)

chown and chgrp - Changing Ownership

chown changes the owner (and optionally group) of a file:

chown alice file.txt              # change owner to alice
chown alice:developers file.txt   # change owner AND group
chown :developers file.txt        # change group only (note leading colon)
chown -R alice:web /var/www/      # recursive ownership change

chgrp changes just the group:

chgrp developers project/
chgrp -R www-data /var/www/html/

umask - Default Permission Mask

umask controls the default permissions assigned to newly created files and directories. It's a mask that removes bits from the maximum possible permission:

• New files start at 666 (rw-rw-rw-)
• New directories start at 777 (rwxrwxrwx)
• The umask is subtracted from these defaults

With umask 022:

• Files: 666 - 022 = 644 (rw-r--r--)
• Dirs: 777 - 022 = 755 (rwxr-xr-x)

A loose umask 000 would create world-writable files by default - a security disaster. If you see services running with an overly permissive umask, that's a finding.

Special Bits: SUID, SGID, and Sticky - The Important Ones

Beyond the standard rwx bits, Linux has three special permission bits. Understanding them is essential for privilege escalation research.

SUID - Set User ID on Execution (4000)

When set on an executable, the program runs with the file owner's privileges, not the calling user's privileges.

ls -la /usr/bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 5 2023 /usr/bin/passwd
     ^
     s = SUID bit (replaces the x in the user execute position)

/usr/bin/passwd needs to write to /etc/shadow (which only root can write). But regular users need to change their own passwords. The SUID bit solves this: when you run passwd, it temporarily runs as root - just long enough to update /etc/shadow.

Why this matters for privilege escalation: If any SUID root binary has a vulnerability or allows you to run arbitrary commands, you get root.

# Classic privilege escalation: find SUID files
find / -perm -4000 -type f 2>/dev/null

Every legitimate SUID binary has a specific, justified reason to run as root. A custom SUID binary in /opt that isn't part of the OS distribution? That's a red flag - check what it does.

SGID - Set Group ID on Execution (2000)

Similar to SUID but for groups. When set on a file, it runs with the file's group's privileges. When set on a directory, files created inside inherit the directory's group (instead of the creator's primary group):

ls -la /usr/bin/write
-rwxr-sr-x 1 root tty 22696 Feb 21 2023 /usr/bin/write
         ^
         s = SGID bit (replaces the x in the group execute position)

# Find SGID files
find / -perm -2000 -type f 2>/dev/null

SGID on directories is often legitimate (shared project directories where all files should belong to a group). SGID on executables deserves the same scrutiny as SUID.

Sticky Bit - Deletion Protection (1000)

The sticky bit on a directory prevents users from deleting files they don't own, even if they have write access to the directory.

/tmp is world-writable (rwxrwxrwx before the sticky bit) - everyone needs to write temp files there. But without the sticky bit, users could delete each other's files. The sticky bit (t) ensures each user can only delete files they own.

Setting special bits:

chmod u+s file.sh          # add SUID (symbolic)
chmod g+s directory/       # add SGID on directory (symbolic)
chmod +t directory/        # add sticky bit (symbolic)
chmod 4755 file.sh         # SUID + rwxr-xr-x (octal: 4 prefix)
chmod 2755 directory/      # SGID + rwxr-xr-x (octal: 2 prefix)
chmod 1777 /tmp            # sticky + rwxrwxrwx (octal: 1 prefix)

Full four-digit octal notation:

  4  7  5  5
  ^  ^  ^  ^
  |  |  |  other
  |  |  group
  |  user
  special: 4=SUID, 2=SGID, 1=sticky

The Privilege Escalation Preview

Here's what a typical privilege escalation check looks like using what you now know:

# Step 1: What SUID binaries exist?
find / -perm -4000 -type f 2>/dev/null
 
# Step 2: Are there world-writable files or directories?
find / -type f -perm -o+w 2>/dev/null | grep -v proc
find / -type d -perm -o+w 2>/dev/null
 
# Step 3: Who owns critical files?
ls -la /etc/crontab /etc/passwd /etc/shadow /etc/sudoers
 
# Step 4: Are there any files owned by our user with elevated permissions?
find / -user $(whoami) -perm -4000 2>/dev/null

Key Takeaways

• Linux permissions are rwx for user, group, and other. The full string looks like -rwxr-xr-x.
• Octal notation: r=4, w=2, x=1. Common patterns: 755 (public binary), 644 (public file), 600 (private key), 700 (private directory).
• chmod changes permissions (octal or symbolic). chown changes owner and group. chgrp changes group only.
• umask sets the default permission mask for new files and directories.
• SUID (4000): Binary runs as file owner (often root) - find these with find / -perm -4000. Non-standard SUID root binaries are prime privilege escalation targets.
• SGID (2000): Binary runs as file's group; on directories, new files inherit the directory's group.
• Sticky bit (1000): On directories, users can only delete their own files. Used on /tmp.
• GTFOBins documents how common binaries with SUID/sudo permissions can escalate privileges.