Linux Deep Dive I

Why Linux, and why this deep

The overwhelming majority of servers you will ever attack run Linux. When you get a foothold, you land in a shell on a Linux box, usually as a low-privileged user, and everything you do next — find secrets, escalate to root, pivot onward — is Linux fluency. Most people "know Linux" the way a tourist knows a city. You need to know it like a local who understands why the streets are laid out the way they are. This lesson is that local's map.

The organising idea of the whole system is simple and worth saying once, plainly: on Linux, almost everything is a file, and every file has an owner and a set of permissions. Master files and permissions and you understand access control, which is what privilege escalation is all about.

The filesystem is a single tree

There are no drive letters. Everything hangs off one root, /, and each directory has a purpose defined by the Filesystem Hierarchy Standard. You don't need all of it; you need the handful an attacker cares about:

Permissions: the ten characters that govern everything

Run ls -l and every file begins with something like -rwxr-xr--. Those ten characters are the entire access-control decision for that file. Read them in four chunks:

So the same permissions have two notations, and you must be fluent in both because tools speak different ones:

• Symbolic: rwxr-xr-- — human-readable, what ls -l shows.
• Octal: add the bits per chunk. rwx = 4+2+1 = 7, r-x = 4+0+1 = 5, r-- = 4+0+0 = 4. So rwxr-xr-- = 754, which is what chmod 754 file sets.

For a directory, the bits mean something slightly different and it trips everyone up: `x` on a directory means "you may enter it" (cd into it, access files inside by name), while `r` means "you may list its contents." You can sometimes access a file inside a directory you cannot list — if you already know the filename and have x on the directory. Attackers exploit exactly that.

The special bits — where privilege escalation lives

Beyond rwx there are three special permission bits, and one of them is the most important concept in Linux privilege escalation.

The SUID bit (`s` in the owner's execute slot). When set on an executable, it makes the program run with the privileges of the file's owner, not the user who launched it. If a binary is owned by root and has SUID set, *anyone* who runs it runs code as root for the duration. That exists for legitimate reasons — passwd needs to edit /etc/shadow, so it's SUID-root — but a misconfigured or abusable SUID-root binary is a direct path from low-privileged user to root.

Users, groups, and processes: who is who

Access is decided by identity, so know how to read identity. Every user has a numeric UID (root is always 0 — that number, not the name, is what confers power) and belongs to one or more groups (each a GID). Membership in the right group (sudo, docker, adm) can be as good as being root.

Processes are just running programs, each owned by a user, each with a PID. Reading the process list tells you what services are running (attack surface), what's running as root (targets), and sometimes secrets passed on a command line (a password in ps output is a real and common find).

Notice how much of this is *reading*, not exploiting. That's the point of foundations: before you can escalate, you have to see clearly — who you are, what you can touch, what runs above you, and which files and bits are out of place. The exploits later are short. The seeing is the skill.