9.1 Linux/Unix Security Architecture, Permissions & Filesystem

9.1 Linux/Unix Security Architecture, Permissions & Filesystem

In Unix and Linux operating systems, security is fundamentally rooted in a multi-user architecture governed by kernel-enforced access controls. Originating from early time-sharing systems, the Unix security model ensures process isolation, resource accounting, and controlled access to files, devices, and network sockets. For penetration testers and security analysts assessing Unix-like environments, a thorough grasp of the underlying security model—specifically how users, groups, and permissions interact—is essential for discovering configuration weaknesses, auditing file systems, and identifying privilege escalation vectors.

---

The Unix Security Model: Discretionary Access Control (DAC)

The classic Unix access model is built upon Discretionary Access Control (DAC). Under DAC, the operating system kernel restricts access to objects (files, directories, devices, IPC mechanisms) based strictly on the identity of the subject (user or process) and the access rules defined for that object. Access is "discretionary" because the owner of an object possesses the administrative authority to grant or revoke read, write, and execute rights to any other user or group on the system.

+-----------------------------------------------------------------------------+
|                        UNIX PROCESS SECURITY CONTEXTS                       |
+-----------------------------------------------------------------------------+
| Real UID (RUID)      : The account that originally spawned the process      |
| Effective UID (EUID) : The active identity used by the kernel for DAC checks|
| Saved UID (SUID)     : Stores previous EUID to permit privilege dropping    |
| Real GID (RGID)      : The primary group of the parent user                 |
| Effective GID (EGID) : The active group identity used for DAC checks        |
| Supplementary Groups : Array of additional group memberships (up to 65,536) |
+-----------------------------------------------------------------------------+

User IDs (UID) and Group IDs (GID)

Every entity within the operating system is tracked numerically:

• User Identifier (UID): An integer assigned to each account. The superuser, root, is uniquely designated by UID 0. The Linux kernel grants UID 0 sweeping administrative authority, bypassing standard DAC file permission checks across the virtual filesystem (VFS).
• System Accounts: Traditionally assigned UIDs between 1 and 999 (or 1–499 on older System V distributions). These accounts (e.g., bin, daemon, www-data, nobody) execute system daemons and services with restricted privileges, enforcing service isolation.
• Interactive Users: Standard human accounts are typically allocated UIDs starting at 1000 (or 500 on legacy Red Hat platforms).
• Group Identifier (GID): An integer representing a collection of users. Every user belongs to a primary group (defined in /etc/passwd) and zero or more supplementary groups (defined in /etc/group).

When a program executes, the kernel tracks both its Real User ID (RUID)—the user who initiated execution—and its Effective User ID (EUID). Under standard conditions, the EUID matches the RUID. However, specialized permission bits can alter this relationship, causing the kernel to evaluate DAC checks against a different identity altogether.

---

Standard File Permissions & Octal Notation

In Unix, "everything is a file"—including hardware devices, network interfaces, named pipes, and directories. Every inode on a filesystem contains metadata recording the file type, size, timestamps, owner UID, owner GID, and a mode word representing its access permissions.

Permissions are divided into three distinct authorization scopes:

1. User / Owner (u): Permissions applied strictly to the user who owns the file.
2. Group (g): Permissions applied to members of the group assigned to the file (excluding the owner).
3. Others (o): Permissions applied to all other authenticated accounts on the system.

Permission Bit Values

Within each scope, three primary permissions can be granted:

• Read (r = 4, binary 100): Grants permission to read the contents of a regular file. On a directory, it allows reading the directory index (e.g., listing filenames via ls).
• Write (w = 2, binary 010): Grants permission to modify or truncate a regular file's content. On a directory, it allows creating, deleting, and renaming files within that directory—provided the execute bit is also set.
• Execute (x = 1, binary 001): Grants permission to execute a binary or shell script. On a directory (known as the search bit), it allows entering the directory (cd), traversing its path, and accessing metadata for files inside it.

  File Mode: - r w x r - x r - -   (Octal: 754)
             | 
             +-- File Type (- = Regular file, d = Directory, l = Symlink)

  User Scope   : r w x  = 4 + 2 + 1 = 7 (Read, Write, Execute)
  Group Scope  : r - x  = 4 + 0 + 1 = 5 (Read, Execute)
  Others Scope : r - -  = 4 + 0 + 0 = 4 (Read Only)

Permission and Ownership Management

• chmod (Change Mode): Modifies file permissions using symbolic syntax (e.g., chmod u+x,g-w script.sh) or octal syntax (e.g., chmod 750 /opt/app).
• chown (Change Owner): Changes the owner UID and optionally the GID (e.g., chown root:admin /var/log/audit.log). Unprivileged users cannot give away ownership of their files to other users on modern Linux systems to prevent quota manipulation and security boundary violations.
• chgrp (Change Group): Modifies the group ownership of an object (e.g., chgrp devops deploy.sh).
• umask (User Mask): Determines default permissions for newly created files and directories by applying a bitwise NOT-AND mask against base modes (666 for files, 777 for directories). A standard umask of 022 results in default file permissions of 644 (rw-r--r--) and directory permissions of 755 (rwxr-xr-x). A hardened umask of 027 creates files as 640 and directories as 750.

---

Special Permissions: SUID, SGID, and the Sticky Bit

To accommodate operational tasks where unprivileged users require transient access to sensitive system resources without full administrative access, Unix provides three special permission bits represented by an additional high-order octal digit.

Special Mode Octal: [Special][User][Group][Others]
Example: 4755 -> SUID (4) + User (7) + Group (5) + Others (5)

+-----------------------------------------------------------------------------+
|                        SPECIAL PERMISSIONS TAXONOMY                         |
+-----------------------------------------------------------------------------+
| Bit   | Octal | Symbolic Indicator | Impact on Executable  | Impact on Directory    |
+-------+-------+--------------------+-----------------------+------------------------+
| SUID  | 4000  | s (or S) on User   | Executes as File Owner| No standard effect     |
| SGID  | 2000  | s (or S) on Group  | Executes as File Group| Group GID Inheritance  |
| Sticky| 1000  | t (or T) on Others | No modern effect      | Deletion Restricted    |
+-----------------------------------------------------------------------------+

1. Set User ID (SUID, Octal 4000)

When set on an executable binary, the kernel automatically sets the process's Effective UID (EUID) to match the file's owner UID, rather than the user invoking the binary.

• Symbolic Representation: An s appears in the user execute position (e.g., -rwsr-xr-x). If the underlying user execute bit is NOT set, an uppercase S appears (e.g., -rwSr-xr-x), indicating an invalid or broken state.
• Legitimate Use Case: The /usr/bin/passwd utility requires root privileges to write user password hashes into /etc/shadow. Because standard users must change their own passwords, /usr/bin/passwd is owned by root and configured with the SUID bit (4755). When an unprivileged user executes passwd, the process temporarily assumes UID 0 rights strictly within the context of that binary.
• Auditing Command: Penetration testers systematically audit filesystems for SUID binaries owned by root:

  find / -perm -u=s -type f 2>/dev/null
  # Or using octal bitmask:
  find / -perm -4000 -type f -exec ls -la {} + 2>/dev/null
  

2. Set Group ID (SGID, Octal 2000)

• On Executables: The process executes with the Effective GID (EGID) of the file's group (e.g., -rwxr-sr-x). Historically utilized by utilities such as /usr/bin/wall or mail delivery agents requiring access to group-restricted spool directories.
• On Directories: When the SGID bit is applied to a directory (chmod 2775 /shared), any newly created file or subdirectory inside it automatically inherits the group ownership of the parent directory, rather than the primary GID of the creating user. This is a standard administrative configuration for collaborative directories.

3. The Sticky Bit (Octal 1000)

• Historical Function: In early Unix, instructed the kernel to retain an executable's program text in swap memory to accelerate subsequent launches.
• Modern Security Function on Directories: Applied to shared, world-writable directories such as /tmp and /var/tmp (mode 1777 or drwxrwxrwt). When the sticky bit is present, only the owner of a file, the directory owner, or the root user can delete, truncate, or rename that file.
• Symbolic Representation: Displayed as a lowercase t in the others execute position (or uppercase T if the others execute bit is missing).

---

Local Privilege Escalation via Misconfigured SUID Binaries

SUID binaries owned by root (UID 0) represent a primary attack surface for local privilege escalation. If an administrative utility, system binary, or custom script with SUID set contains command execution functionality, shell escape features, or arbitrary file access primitives, an unprivileged user can compromise the system.

The open-source security reference GTFOBins curates legitimate Unix binaries that can be abused to bypass local security restrictions.

Attacker (UID 1001) ---> Invokes SUID Binary (Owned by Root, UID 0)
                                |
                                v
                 Kernel sets Process EUID = 0
                                |
                                v
             Binary spawns subshell or executes code
                                |
                                v
                     Interactive Root Shell (#)

Notable GTFOBins Exploitation Examples

1. find (SUID): The find utility supports the -exec flag to execute commands against matched files. If find has SUID permissions:

   find . -exec /bin/sh -p \; -quit
   

   The -p (privileged) flag instructs /bin/sh or /bin/bash not to drop effective user privileges upon invocation.

2. vim / vi (SUID): Text editors with shell escape capabilities can spawn root shells directly from command mode:

   vim -c ':!/bin/sh'
   

3. nmap (Legacy SUID): Older versions of Nmap (prior to version 5.21) included an interactive mode (--interactive) designed for user convenience, which permitted shell execution:

   nmap --interactive
   nmap> !sh
   

4. Arbitrary File Overwrite (cp / install / tee): If utilities capable of writing files possess SUID root permissions, an attacker can overwrite critical system databases (such as /etc/passwd or /etc/shadow) to inject new administrative credentials.

---

Core Unix Credential Files

Unix-like systems store identity, group, and credential data across standardized plaintext databases in /etc.

+-----------------------------------------------------------------------------+
|                          CORE UNIX CREDENTIAL FILES                         |
+-----------------------------------------------------------------------------+
| File         | Permissions | Owner:Group | Contents                         |
+--------------+-------------+-------------+----------------------------------+
| /etc/passwd  | 0644 (-rw-r--r--) | root:root   | User metadata & account definitions|
| /etc/shadow  | 0640 (-rw-r-----) | root:shadow | Cryptographic password hashes    |
| /etc/group   | 0644 (-rw-r--r--) | root:root   | Group definitions & memberships  |
| /etc/sudoers | 0440 (-r--r-----) | root:root   | Administrative privilege rules   |
+-----------------------------------------------------------------------------+

1. /etc/passwd

The /etc/passwd file defines user accounts and environment properties. It must remain world-readable (0644) so that standard utilities (such as ls and ps) can translate numeric UIDs into alphanumeric usernames.

Each line contains seven colon-delimited fields:

root:x:0:0:root:/root:/bin/bash
 |   | | |   |    |      |
 |   | | |   |    |      +-- 7. Default Login Shell (/bin/bash, /sbin/nologin)
 |   | | |   |    +--------- 6. Home Directory Path (/root, /home/user)
 |   | | |   +-------------- 5. GECOS field (User full name, office, phone)
 |   | | +------------------ 4. Primary Group ID (GID 0)
 |   | +-------------------- 3. User ID (UID 0)
 |   +---------------------- 2. Password Placeholder ('x' points to /etc/shadow)
 +-------------------------- 1. Username

Exploitation of Writable /etc/passwd

If an administrator misconfigures /etc/passwd with world-writable permissions (0666 or 0646), any unprivileged user can gain immediate root privileges by appending a custom superuser account:

# Generate a SHA-512 password hash for 'password123'
openssl passwd -6 -salt evil password123
# Hash output: $6$evil$1q2w3e4r5t6y...

# Append custom UID 0 user to /etc/passwd
echo 'hacker:$6$evil$1q2w3e4r5t6y...:0:0:SuperUser:/root:/bin/bash' >> /etc/passwd

# Switch to the new root user
su hacker

Alternatively, if the password placeholder (x) in the root entry is deleted entirely (root::0:0:...), the system permits logging in as root without supplying any password.

2. /etc/shadow

To prevent unprivileged users from extracting password hashes for offline cracking, Unix systems store password hashes in /etc/shadow. Access is strictly restricted to administrative accounts (permissions 0640 owned by root:shadow or 0600 owned by root:root).

Each line contains nine colon-delimited fields:

admin:$6$rounds=5000$saltstring$hashdata:19736:0:90:7::: 
  |                   |                    |   |  |  | | | |
  |                   |                    |   |  |  | | | +-- 9. Reserved
  |                   |                    |   |  |  | | +---- 8. Account expiration date
  |                   |                    |   |  |  | +------ 7. Inactivity period
  |                   |                    |   |  |  +-------- 6. Warning days before expiry
  |                   |                    |   |  +----------- 5. Maximum password age (days)
  |                   |                    |   +-------------- 4. Minimum password age (days)
  |                   |                    +------------------ 3. Last password change date
  |                   +--------------------------------------- 2. Cryptographic Hash ($id$salt$hash)
  +----------------------------------------------------------- 1. Username

Cryptographic Hash Identifiers ($id$)

The hash field utilizes the modular crypt format, where the prefix between the first and second dollar signs identifies the hashing algorithm:

If the password field contains an exclamation mark (!) or asterisk (*), the account is locked or disabled for password-based logins (common for system daemons).

---

The Sudoers Framework & Privilege Delegation

The sudo (SuperUser DO) framework delegates granular administrative privileges to authenticated users without sharing the root password. Configuration is centrally managed in /etc/sudoers and drop-in files within /etc/sudoers.d/. Because syntax errors in /etc/sudoers can permanently lock administrators out of privileged execution, modifications should always be conducted via the visudo command, which validates syntax before committing changes to disk.

Sudoers Syntax Breakdown

username / %groupname   hostname=(runas_user:runas_group)   [TAGS:] commands

• %wheel ALL=(ALL:ALL) ALL: Members of the wheel group can execute any command as any user and group on any host, requiring their own password for authentication.
• developer ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx: User developer can restart the Nginx service as root without entering a password.

Sudo Enumeration & Exploitation (sudo -l)

During an assessment, an analyst should immediately inspect assigned sudo privileges using:

sudo -l

If an entry permits executing commands with wildcard characters (*), shell interpreters (bash, sh, python, perl), or utilities with shell escape sequences (e.g., sudo less /var/log/syslog -> typing !/bin/sh), the analyst can obtain an interactive root shell. Furthermore, if NOPASSWD: is misapplied to an administrative script that is world-writable, modifying the script body yields unprompted root execution.