ES1.7 Linux Authentication and Privilege Model

PAM: the authentication gateway

Pluggable Authentication Modules is the framework through which every Linux authentication event passes. When a user logs in via SSH, types a password for sudo, or authenticates to any PAM-aware service, the request passes through a stack of PAM modules defined in configuration files under /etc/pam.d/. Each module performs a specific function: pam_unix checks the password against /etc/shadow, pam_faillock tracks failed attempts, pam_tally2 enforces lockout policies, pam_google_authenticator provides TOTP-based MFA.

The security implication is dual. PAM is your authentication enforcement point — properly configured, it enforces password complexity, account lockout, MFA, and session controls. But PAM is also an attack surface. An attacker with root access can install a malicious PAM module that logs every password entered on the system (credential harvesting), bypasses authentication entirely (replacing pam_unix with pam_permit), or creates a backdoor that accepts a hardcoded password alongside the legitimate one. The PAM configuration files themselves are high-value targets — a single-line change in /etc/pam.d/sshd can disable authentication for the SSH service.

Sudo: the privilege boundary

Sudo is the primary mechanism for privilege escalation on Linux — the legitimate mechanism. The /etc/sudoers file (and files in /etc/sudoers.d/) defines which users can execute which commands as which other users. A properly configured sudoers file implements least privilege: the web application service account can restart nginx but cannot modify system files. The database administrator can run database maintenance commands but cannot install packages.

Misconfigured sudoers is one of the most common Linux privilege escalation vectors. Common misconfigurations include: ALL=(ALL) NOPASSWD: ALL (user can run any command as root without a password), user ALL=(ALL) NOPASSWD: /usr/bin/vi (the user can run vi as root, then use :!bash to spawn a root shell — GTFOBins), user ALL=(ALL) NOPASSWD: /usr/bin/find (find has an -exec flag that executes arbitrary commands). The GTFOBins project (gtfobins.github.io) catalogues hundreds of Unix binaries that can be abused for privilege escalation when available through sudo.

The endpoint security controls for sudo: audit logging of all sudo commands (enabled by default in most distributions via auth.log or journalctl), auditd rules that monitor /etc/sudoers modifications, Sysmon for Linux Event ID 1 that captures the process creation when sudo is invoked (including the full command line), and regular review of the sudoers file to identify overly permissive configurations. The Defender for Linux agent (mdatp) detects some sudo abuse patterns, but sudoers misconfiguration is primarily a hardening problem — reduce the permissions to the minimum necessary.

SUID/SGID: inherited privilege

SUID (Set User ID) and SGID (Set Group ID) are file permission flags that change the execution context of a binary. When a binary has the SUID flag set, it runs with the permissions of the file owner (usually root), regardless of which user invokes it. This is by design — /usr/bin/passwd needs SUID because changing a password requires writing to /etc/shadow, which only root can modify. /usr/bin/ping historically needed SUID to open raw sockets.

The attack surface: any SUID-root binary with a vulnerability (buffer overflow, command injection, library injection) gives the attacker root access. Custom SUID binaries installed by administrators or applications are particularly dangerous because they receive less security scrutiny than system binaries. An attacker’s first reconnaissance on a Linux system often includes find / -perm -4000 -type f 2>/dev/null — enumerate all SUID binaries, then check each against known exploitation databases.

The defensive controls: regular SUID auditing (scheduled find command that compares current SUID binaries against a known-good baseline), mounting non-system partitions with the nosuid option (prevents SUID from functioning on files in those partitions), and file integrity monitoring that alerts when new SUID binaries appear. Modern Linux distributions have reduced SUID usage — many binaries that historically required SUID now use capabilities instead — but legacy applications and custom installations often introduce new SUID binaries without security review.

Capabilities: fine-grained root powers

Linux capabilities decompose root’s monolithic privilege into 40+ individual capabilities. CAP_NET_RAW allows opening raw sockets. CAP_SYS_ADMIN is a broad capability that covers mounting filesystems, loading kernel modules, and other administrative operations. CAP_DAC_OVERRIDE allows bypassing file permission checks. Instead of making a binary SUID root (granting all root powers), an administrator can assign specific capabilities: setcap cap_net_raw+ep /usr/bin/ping gives ping the ability to open raw sockets without making it SUID.

Capabilities reduce the attack surface compared to SUID because a compromised capability-enabled binary only gains the specific capabilities assigned, not full root. But they introduce a new enumeration vector: getcap -r / 2>/dev/null lists all capability-enabled binaries, and certain capabilities (particularly CAP_SYS_ADMIN, CAP_SYS_PTRACE, and CAP_DAC_OVERRIDE) can be leveraged for privilege escalation. Container escapes frequently exploit capabilities — a container running with CAP_SYS_ADMIN can mount the host filesystem.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# Sudo permissions for the current user
sudo -l

# SUID binaries
find / -perm -4000 -type f 2>/dev/null

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

# Capability-enabled binaries
getcap -r / 2>/dev/null

# Writable directories in PATH
echo $PATH | tr ':' '\n' | xargs -I {} find {} -writable -type d 2>/dev/null

# Cron jobs running as root
cat /etc/crontab 2>/dev/null
ls -la /etc/cron.d/ 2>/dev/null

Troubleshooting

“Our Linux servers use service accounts that require passwordless sudo for automation scripts.” This is common and creates a privilege escalation path. Mitigate by: restricting the NOPASSWD sudo entries to the specific commands the automation requires (not ALL), ensuring the specified commands cannot be used for shell escapes (check GTFOBins), and adding auditd rules that monitor all sudo invocations by service accounts. The goal is not to eliminate passwordless sudo — it is to restrict it to the minimum necessary commands with monitoring.

“We cannot install endpoint security agents on our Linux servers because the operations team says it will affect performance.” Deploy Defender for Linux (mdatp) on a non-production server first. Measure CPU and memory impact during normal workload. The mdatp agent’s real-time protection uses eBPF for kernel monitoring (on supported kernels) with minimal overhead. If performance impact is measurable on specific workloads (database servers under heavy IO), configure exclusions for the specific directories causing the impact (database data files, log directories). Module ES13 covers server-specific Linux endpoint security configuration.