9.1 Linux/Unix Security Architecture, Permissions & Filesystem

CREST Practitioner Security Analyst CPSA

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Soft Skills, Legal Framework & Assessment Management

1.1 The Penetration Testing Engagement Lifecycle & Scoping 1.2 Legal Framework: Computer Misuse Act & Compliance 1.3 Understanding, Explaining & Managing Technical Risk 1.4 Record Keeping, Interim Escalation & Reporting Standards

2 Chapter 2: Core Networking: IP Protocols & Network Architectures

2.1 IPv4 and IPv6 Addressing, Subnetting & Header Architecture 2.2 TCP and UDP Transport Protocols & Handshake Mechanics 2.3 ICMP Protocol, Network Diagnostics & Error Messages 2.4 Network Topologies, Switched Media & VLAN Segmentation 2.5 Network Media, Ethernet Standards & Physical Topologies

3 Chapter 3: Cryptography & Secure Communication Protocols

3.1 Symmetric & Asymmetric Cryptographic Algorithms 3.2 Cryptographic Hash Functions, MACs & Digital Signatures 3.3 Secure Protocols: SSL/TLS, IPsec & SSH

4 Chapter 4: Background Information Gathering & OSINT Reconnaissance

4.1 WHOIS Records, Domain Registrars & Autonomous Systems 4.2 DNS Infrastructure, Record Types & Zone Transfers 4.3 Search Engine Reconnaissance, Google Dorking & Information Leakage 4.4 Newsgroups, Mailing Lists & Public Archive Reconnaissance

5 Chapter 5: Networking Equipment & Infrastructure Protocols

5.1 Router & Switch Management: SNMP, SSH & Authentication 5.2 Layer 2 Protocols: ARP, CDP, STP, VTP & Redundancy 5.3 Core Network Services: DHCP, NTP & TFTP 5.4 Wireless Security (802.11) & VoIP Assessment 5.5 Out-of-Band Management, Console Access & Cisco Reverse Telnet

6 Chapter 6: Network Mapping, Nmap Techniques & Target Identification

6.1 Host Discovery Techniques & Ping Sweep Methodologies 6.2 Port Scanning Mechanics: TCP, UDP & Stealth Scans 6.3 OS Fingerprinting, Service Detection & Timing Templates 6.4 Firewall and IDS/IPS Evasion Techniques 6.5 Passive OS & Service Fingerprinting 6.6 Network Access Control Analysis & Firewall Rule Base Review

7 Chapter 7: Vulnerability Identification & Tool Output Analysis

7.1 Vulnerability Scanning Principles & Methodology 7.2 CVE Referencing, CVSS Scoring & Risk Prioritisation 7.3 Banner Grabbing, Service Verification & Manual Triage 7.4 Host Audit Techniques: Processes, Sockets, Patch Levels & Interesting Files

8 Chapter 8: Microsoft Windows Security Assessment & Active Directory

8.1 Active Directory Architecture & Domain Reconnaissance 8.2 Windows User & Group Enumeration via SMB & RPC 8.3 Windows Authentication: NTLM, Kerberos & Password Security 8.4 Windows Patch Management, Local Security & Common Services 8.5 Windows File System, Share & Registry Permissions 8.6 Desktop Lockdown, Citrix Breakout & Common Windows Applications

9 Chapter 9: Unix & Linux Security Assessment & Legacy Services

9.1 Linux/Unix Security Architecture, Permissions & Filesystem 9.2 Unix User Enumeration & Service Discovery 9.3 Network File System (NFS) & RPC Services Assessment 9.4 Legacy Unix Services: R-Services, X11, FTP & Modern SSH 9.5 Unix Remote Information Services: rusers, rwho, finger & systat 9.6 Unix Vulnerability Exploitation & Post-Exploitation Workflow

10 Chapter 10: Web Architectures, Technologies & Testing Methodologies

10.1 Web Server Architecture & the HTTP/HTTPS Protocol 10.2 Web Application Components, Frameworks & State Management 10.3 Web Reconnaissance, Content Discovery & Threat Modelling 10.4 Testing Authentication, Authorization & Session Management 10.5 Web Service Protocols: SOAP, REST & XML Messaging 10.6 Web APIs, Server Extensions & Client-Side Sub-Components

11 Chapter 11: Web Testing Techniques & OWASP Top Vulnerabilities

11.1 Input Validation Vulnerabilities & Parameter Manipulation 11.2 Cross-Site Scripting (XSS): Types, Impact & Defenses 11.3 Cross-Site Request Forgery (CSRF) & Client-Side Attacks 11.4 Command Injection, File Upload Vulnerabilities & API Flaws 11.5 Information Disclosure: Error Messages & Mark-up Leakage 11.6 Injection Beyond SQL: LDAP, XPath, Code & Template Injection 11.7 Source Code Review & Encoded/Cryptographic Value Analysis

12 Chapter 12: Database Security Assessment & SQL Injection

12.1 Database Architectures, Default Ports & Authentication 12.2 SQL Injection (SQLi) Foundations & In-Band Techniques 12.3 Blind SQL Injection & Database Enumeration 12.4 Database Attack Vectors, Stored Procedures & Hardening

9.1 Linux/Unix Security Architecture, Permissions & Filesystem

Key Takeaways Explain This Topic AI

The Unix security architecture implements Discretionary Access Control (DAC), where every process and file is bound to a User ID (UID) and Group ID (GID), with UID 0 (root) possessing complete bypass capabilities over standard permission checks.

Standard permissions enforce Read (4), Write (2), and Execute (1) across Owner, Group, and Others, while special permission bits introduce elevated execution contexts via SUID (4000) and SGID (2000), or directory deletion safeguards via the Sticky Bit (1000).

Misconfigured SUID binaries owned by root represent one of the most critical local privilege escalation vectors, enabling attackers to escape restricted environments using administrative utilities catalogued in GTFOBins (e.g., find, vim, nmap, bash).

The Unix credential architecture splits user metadata in /etc/passwd (world-readable) from cryptographic password hashes in /etc/shadow (restricted to root/shadow), where hash algorithms are distinguished by standardized prefixes ( 1 1 1 for MD5, 6 6 6 for SHA-512, and y y y for yescrypt).

Last updated: September 2026

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:

User / Owner ( u ): Permissions applied strictly to the user who owns the file.

Group ( g ): Permissions applied to members of the group assigned to the file (excluding the owner).

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)

Octal Value Symbolic Notation File Capabilities Directory Capabilities
7 rwx Read, modify, execute binary List contents, create/delete files, traverse ( cd )
6 rw- Read, modify, cannot execute Read file list, create/delete, cannot traverse
5 r-x Read, execute, cannot modify List files, traverse ( cd ), cannot create/delete
4 r-- Read only List files only, cannot access inode metadata
0 --- No access whatsoever Completely inaccessible
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

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.

vim / vi (SUID): Text editors with shell escape capabilities can spawn root shells directly from command mode: vim -c ':!/bin/sh'

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

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:

Prefix Algorithm Key Characteristics & Security Posture
$1$ MD5-based crypt Obsolete; vulnerable to rapid GPU cracking via Hashcat/John
$2a$ / $2y$ Blowfish (bcrypt) Strong, configurable work factor; standard in OpenBSD
$5$ SHA-256 crypt Default 5,000 rounds; resilient against simple dictionary attacks
$6$ SHA-512 crypt Default 5,000 rounds; standard across enterprise Linux (RHEL/Ubuntu)
$y$ yescrypt Modern memory-hard function; default in Debian 11+ and Ubuntu 22.04+

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.