Building on our filesystem knowledge, we now tackle one of the most critical security concepts in Linux: user and permission management. Linux is a multi-user operating system with a robust discretionary access control (DAC) model. Understanding how users, groups, and file permissions work is essential for both securing systems and identifying misconfigurations during audits.
Linux stores user account information in two files. /etc/passwd contains account details and is world-readable. /etc/shadow contains encrypted password hashes and is readable only by root. This separation is a fundamental security design.
Each /etc/passwd field is colon-separated: username:password_placeholder:UID:GID:description:home_directory:shell. The /etc/shadow fields include: username:password_hash:last_change:min_age:max_age:warning:inactive:expire.
Every user has a User ID (UID) and belongs to at least one group with a Group ID (GID). These numeric identifiers are what the kernel actually uses for access control — usernames are just human-friendly labels.
| UID Range | Type | Security Note |
|---|---|---|
| 0 | root user | Full system access — protect at all costs |
| 1-999 | System/service accounts | Should never have login shells |
| 1000+ | Regular human users | Standard user accounts |
| 65534 | nobody/nogroup | Used for unprivileged operations |
⚠️ Any account with UID 0 has root privileges, regardless of its username. During audits, always check for unauthorized UID 0 accounts with: awk -F: '$3 == 0 {print $1}' /etc/passwd
Linux file permissions are the primary access control mechanism. Every file has three permission sets: owner (u), group (g), and others (o). Each set can have read (r=4), write (w=2), and execute (x=1) permissions.
Permission Breakdown:
-rwxr-xr-- 1 root root 8192 Jan 15 10:00 /usr/bin/example
|---|||---||---|
| | | | |
| | | | └── Others: r-- = read only (4)
| | | └──── Group: r-x = read + execute (5)
| | └──────── Owner: rwx = read + write + execute (7)
| └────────── File type: - = regular file
└────────────── Permission string
Numeric notation: rwxr-xr-- = 754Security professionals frequently need to set correct permissions on sensitive files and audit existing permissions for misconfigurations.
Beyond standard permissions, Linux has three special permission bits that are critical for security professionals to understand — and to audit for abuse.
| Permission | Numeric | On Files | On Directories |
|---|---|---|---|
| SUID (Set User ID) | 4000 | Execute as file owner | No effect |
| SGID (Set Group ID) | 2000 | Execute as file group | New files inherit group |
| Sticky Bit | 1000 | No effect | Only owner can delete files |
SUID is the most dangerous special permission. When set on an executable, it runs with the file owner's privileges — not the executing user's. This is how /usr/bin/sudo works, but attackers also abuse SUID binaries for privilege escalation.
💡 During penetration tests, always run the SUID find command. Unexpected SUID binaries (especially custom scripts or copies of /bin/bash) are a common privilege escalation path. GTFOBins (gtfobins.github.io) catalogs how each SUID binary can be abused.
Rather than sharing the root password, Linux uses sudo to grant specific users the ability to run specific commands as root. The /etc/sudoers file defines these privileges and must be carefully configured.
# /etc/sudoers examples:
# Allow user to run ALL commands as root (DANGEROUS)
analyst ALL=(ALL:ALL) ALL
# Allow user to run specific commands only
analyst ALL=(root) /usr/bin/systemctl restart apache2
# Allow group to run commands without password (RISKY)
%admin ALL=(ALL) NOPASSWD: ALL
# Allow user to run commands as specific user
backup ALL=(postgres) /usr/bin/pg_dump⚠️ Never grant NOPASSWD: ALL to any user or group. This is equivalent to giving them root access without audit logging. Always specify exact commands and require password authentication.
Verify exercises to earn ★ 140 XP and unlock next lab level.