Linux Privilege Escalation: How It Really Happens and How Defenders Stop It

Interviewers ask about Linux privilege escalation to see whether you think like an attacker who already has a foothold, and whether you can turn that into concrete hardening. The good news is that the main paths are few and predictable.

Start from the foothold

Assume an attacker has a shell as an unprivileged service account, for example the web server's user. Their goal is root. They will look for the cheapest change in what the kernel lets them do.

How each path works

Writable things that root runs. If root runs a script from cron, and the service account can edit that script or its directory, the next run executes the attacker's code as root. The same applies to service binaries, libraries in writable directories and configuration files that a privileged process trusts.

Sudo rules. A rule allowing an editor, pager, interpreter or archive tool as root is a rule allowing root, because those programs can start shells or write files. Wildcards in arguments make it worse.

Setuid programs and file capabilities. These run with elevated privilege whoever starts them. Any bug in how they handle arguments, environment or files they read becomes an escalation path.

Credentials on disk. Database passwords in configuration files, keys in shell history and backups readable by everyone often give access to more privileged accounts or other systems.

Kernel vulnerabilities. When configuration is clean, attackers look for a public local exploit for the kernel version. On container hosts this is also a container escape, because containers share the kernel.

What defenders do

Run services as dedicated accounts with no shell and no sudo. Keep everything a privileged process executes or loads root-owned. Remove setuid binaries you do not need and audit file capabilities. Keep secrets out of files where possible. Patch kernels promptly, reduce reachable kernel surface with seccomp and by disabling unused modules, and keep SELinux or AppArmor enforcing. Alert on new setuid files, changes to sudoers and unexpected privilege changes.

Mistakes interviewers notice

The most common weak answer jumps straight to kernel exploits and tools. It sounds technical, but it misses where real escalations come from and says nothing about how to prevent them. Another weak pattern lists commands without explaining why each check matters, which falls apart at the first follow-up question.

A stronger answer explains the principle underneath every path: the kernel makes a more generous decision because something trusted by a privileged process can be influenced by a less privileged one. Once you say that, the defences follow naturally, and you can handle variants you have never seen, such as a writable systemd unit, a library directory on a shared mount or an environment variable passed to a privileged wrapper. Interviewers are listening for that principle, because it is what lets a security engineer review an unfamiliar system rather than run a checklist.

A compact model answer

"From a service-account foothold I would look for writable files that root runs, permissive sudo rules, setuid helpers, credentials on disk and finally kernel exploits. Defending is the mirror image: nothing a privileged process uses should be writable by less privileged accounts, sudo grants narrow wrappers, setuid binaries are minimal, secrets live in a manager, and kernels are patched with seccomp and mandatory access control limiting the rest."

Where to go deeper

Start with privilege escalation basics, then PAM and sudo, Linux capabilities and how kernel bugs become privilege escalation. The Security Fundamentals course covers the kernel's role in its second module.