Linux Security

Most of the world’s servers, containers, and cloud workloads run on Linux, which means most real attacks eventually touch a Linux host. Understanding how the system decides who you are, what you can run, and what you can reach is the difference between a box that shrugs off a mistake and one that hands an attacker root. This foundation is hands-on: you build a disposable lab, break things safely, and see the security model react. This overview maps the terrain so the later sections have a place to hang.

The Layers Of A Linux Host

Security on a Linux host is not one control. It is a stack of layers, each of which can be strong or weak independently. An attacker only needs one weak layer; a defender has to think about all of them.

Layer	What it governs	Example weakness
Accounts	Who you are: users, groups, UIDs	Shared logins, weak passwords, stale accounts
Processes	What runs and with which identity	A service running as root that need not be
Filesystem	What each identity can read or write	World-writable configs, stray setuid binaries
Network	What is reachable from outside	A database bound to 0.0.0.0 with no firewall
Kernel	The boundary all of the above sit on	Missing seccomp, an unpatched local exploit

The layers are ordered roughly from the outside in. Network exposure is what an external attacker sees first; the kernel is the last wall standing once they have local code execution. A good mental model when you read any advisory or run any audit is to ask “which layer is this, and what sits above and below it?”

How Privilege Actually Works

Linux enforces almost everything through a small number of primitives. Each process carries a user ID (UID) and one or more group IDs. Files carry an owner, a group, and permission bits. When a process tries to open a file, the kernel compares the two and answers yes or no. root (UID 0) bypasses most of these checks, which is why so much of security is about keeping code out of UID 0 and shrinking what root-owned code does.

On top of that base sit the mechanisms this foundation explores: sudo for delegating specific root actions, setuid binaries for controlled privilege transitions, ACLs and capabilities for finer grants than the classic bits allow, and Linux Security Modules (AppArmor on Ubuntu) for mandatory policy the file owner cannot override. Misconfiguration in any of these is a common escalation path, so you learn to spot and audit each one.

How This Foundation Is Structured

The sections build on each other. Later material assumes you have the earlier lab set up and the earlier concepts in hand.

• Getting Started stands up the lab and teaches you to look around a host: identity, running processes, and listening ports. See Local Setup, Explore The System, and Verify The Environment.
• Users & Permissions is the core of the access model: Users & Groups, File Permissions, Sudo, Setuid & Setgid, and ACLs & Attributes. This is where most day-to-day hardening and most local privilege escalation both live.
• Later groups extend outward into processes, networking, and kernel-level controls, reusing the same lab.

Work through them in order the first time. After that, each page stands alone as a reference.

Using The Lab

Every exercise runs in a throwaway Ubuntu 24.04 LTS virtual machine, never on your daily driver. You will deliberately create weak permissions, exposed services, and misconfigured sudo rules, then observe and fix them. The whole point is that mistakes are free: take a snapshot before an exercise and roll back after. Local Setup covers launching the VM and snapshots in detail.

multipass launch --name lab 24.04
multipass shell lab

Expected output:

Launched: lab
Welcome to Ubuntu 24.04.2 LTS (GNU/Linux 6.8.0-45-generic x86_64)
ubuntu@lab:~$

A Starting Hardening Baseline

Before diving into individual topics, it helps to have a baseline in your head of what a reasonably hardened host looks like. You will justify each item in later sections; for now, treat it as the target.

• Every service runs as an unprivileged, dedicated user, not root.
• Only the ports you intend to serve are listening, and a firewall blocks the rest.
• No unexpected setuid binaries exist, and sudo grants are specific rather than blanket ALL.
• Accounts map to real people or real services, with no shared or orphaned logins.
• The kernel is patched, and mandatory access control (AppArmor) is enforcing.

Practical Guidance

1. Build the lab VM first and snapshot it clean; do not read further until multipass shell lab works.
2. When you learn a control, immediately try to bypass it in the lab. You understand a defense best after you have defeated a weak version of it.
3. For any finding, name the layer (account, process, filesystem, network, kernel) so you know which section covers the fix.
4. Keep root out of your workflow: log in as a normal user and reach for sudo only for the specific action that needs it.
5. Revisit the hardening baseline after each group and check the lab against it; the list should feel more concrete each time.