Linux Fundamentals, History & Filesystem Hierarchy
Beginner75 min read
You are in the Foundations track. Everything in this notebook — every hack, every defense, every tool — runs on Linux or talks to something that does. This chapter builds the mental model the entire series sits on. Skip nothing.
Why Every Cybersecurity Professional Must Know Linux
Let’s start with a raw fact: over 96% of the top one-million web servers run Linux. Every major cloud provider (AWS, GCP, Azure) runs Linux-based infrastructure under the hood. Almost every offensive security tool — Nmap, Metasploit, Burp Suite, Wireshark, BloodHound, Volatility — was written for and runs best on Linux. Android, which powers ~72% of mobile devices worldwide, is built on the Linux kernel.
When you compromise a server, you’re almost certainly landing on a Linux box. When you run your pentest tools, you’re on Kali Linux or Parrot OS. When you analyze malware in a sandbox, you’re in a Linux VM. When you set up detection pipelines, you’re configuring Linux services. This is not optional background knowledge — it is the substrate of everything.
“Not knowing Linux in cybersecurity is like not knowing anatomy in medicine. You can fake it for a while, but you’ll get exposed at the worst possible moment.”
This chapter teaches you Linux from the absolute beginning with the depth a professional needs. By the end you will understand: what Linux actually is and where it came from, how the kernel, shell, and terminal relate to each other, the complete filesystem hierarchy and why each directory exists, exactly which paths matter for security (and why attackers love /tmp and /etc), and the “everything is a file” philosophy that makes Linux so powerful and so exploitable.
Part 1: What Is Linux? A Brief History That Actually Matters
To understand Linux, you must understand Unix. In 1969, AT&T Bell Labs engineers Ken Thompson and Dennis Ritchie created Unix — a multi-user, multi-tasking operating system designed for simplicity, portability, and elegance. Unix introduced ideas that are still alive today: pipes, plain-text config files, a hierarchical filesystem, and the philosophy “do one thing, do it well.” Every modern operating system — macOS, iOS, Android, Linux — is either a Unix descendant or heavily Unix-inspired. Windows is the odd one out.
Unix was proprietary and expensive. Universities licensed it but couldn’t freely modify it. In 1983, Richard Stallman launched the GNU Project — “GNU’s Not Unix” — to create a completely free, open-source Unix replacement. GNU produced critical tools: the GCC compiler, the bash shell, grep, sed, awk, emacs. But GNU had no kernel.
In August 1991, a 21-year-old Finnish student named Linus Torvalds posted a message to the comp.os.minix newsgroup:
"I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones."
That hobby project was the Linux kernel — the core of an operating system that manages hardware, memory, processes, and system calls. Torvalds combined his kernel with GNU’s tools, and GNU/Linux was born. Today when people say “Linux,” they usually mean the Linux kernel; a “Linux distribution” packages that kernel with GNU tools, a package manager, a desktop environment, and software.
Why does this history matter for security? Because Linux is open source — its source code is publicly auditable. When a kernel vulnerability is found (like Dirty COW, CVE-2016-5195, or the Dirty Pipe vulnerability, CVE-2022-0847), security researchers can read the exact code, understand the bug, write exploits, and also write patches — all in the open. Understanding where Linux came from helps you understand why it behaves the way it does.
A distribution (distro) is Linux + a package manager + bundled software. Different distros serve different purposes. As a security professional you’ll encounter three major families:
Family
Key Distros
Package Manager
Package Format
Security Use
Debian
Debian, Ubuntu, Kali Linux, Parrot OS
apt / dpkg
.deb
Kali/Parrot are the industry-standard pentest distros
Red Hat
RHEL, CentOS, Fedora, Rocky Linux, AlmaLinux
dnf / yum / rpm
.rpm
Dominant in enterprise servers you’ll target or defend
Arch
Arch Linux, Manjaro, BlackArch
pacman
custom
BlackArch has 2,800+ security tools; rolling release
For this roadmap: You’ll do early exercises on any Linux (Ubuntu, WSL on Windows, or a VM). Once you hit the offensive security phases, you’ll move to Kali Linux — a Debian-based distro maintained by Offensive Security and pre-loaded with hundreds of pentest tools. Every tool we install or use will include Kali-compatible install instructions.
Quick distro identification command:
Terminal window
cat/etc/os-release
Learn this now. You’ll use it the moment you get a shell on an unknown system.
Part 2: The Three Layers — Kernel, Shell, Terminal
This is the most commonly confused concept for beginners. These three things are not the same, and confusing them will cause you to misunderstand how attacks and defenses work.
The kernel is the privileged core of the operating system. It is the only program that runs in “kernel space” (ring 0 on x86 architecture), with direct access to hardware. Everything else — every app, every shell, every tool you run — lives in “user space” (ring 3) and must ask the kernel permission to do anything hardware-related via system calls (syscalls).
When Nmap sends a packet, it’s calling the kernel’s network stack. When Volatility reads a memory image, it’s working with kernel data structures. When you chmod a file, you’re calling the chmod syscall. When a rootkit hides a process, it’s hooking kernel functions to lie about what’s running.
The kernel manages:
Process scheduling — which process runs on which CPU core, for how long
Kernel vulnerabilities are the most dangerous class. A kernel exploit gives you ring-0 code execution — complete system control, often with no way to detect or stop it from user space. Examples:
CVE-2016-5195 (Dirty COW) — race condition in copy-on-write; allowed any local user to write to read-only memory mappings → privilege escalation to root on millions of Android phones and Linux servers
CVE-2022-0847 (Dirty Pipe) — allowed overwriting data in arbitrary read-only files; affected kernel 5.8+
CVE-2021-4034 (PwnKit) — privilege escalation via pkexec; not in the kernel itself but in a setuid binary that interfaces with it
The shell is a program running in user space that reads your commands, parses them, and executes them. It’s not magic — it’s a program like any other. The default shell on most Linux distros is bash (Bourne Again Shell). Kali Linux uses zsh with Oh My Zsh since version 2020.4.
Terminal window
# Check your current shell
echo $SHELL # e.g. /bin/bash or /bin/zsh
# Check all available shells
cat/etc/shells
# Switch to bash temporarily
bash
# See what bash actually is
file/bin/bash# /bin/bash: ELF 64-bit LSB pie executable, x86-64
What the shell does when you type ls -la /etc:
Reads your input: ls -la /etc
Parses it: command = ls, arguments = -la, /etc
Looks up ls in $PATH directories: finds /bin/ls
Forks a child process
Calls execve("/bin/ls", ["ls", "-la", "/etc"], environ) — a syscall to the kernel
The kernel loads and executes /bin/ls
/bin/ls uses other syscalls (openat, getdents64, write) to read the directory and print results
The process exits; the shell returns to its prompt
Security relevance: Shell injection vulnerabilities exist because web apps and scripts sometimes build shell commands from user input. If a web app does os.system("ping " + user_input) and you provide ; cat /etc/passwd, the shell parses ; as a command separator and executes both. Understanding the shell is prerequisite to understanding command injection.
The terminal (or terminal emulator) is just the window that hosts the shell. It converts your keystrokes into characters the shell sees, and renders the shell’s text output on screen. gnome-terminal, xterm, Alacritty, iTerm2, Windows Terminal, and the SSH client on your machine are all terminals.
When you SSH into a remote server, your local terminal talks to a remote shell. The terminal is on your machine; the shell runs on the server. This is why you can redirect a remote shell over SSH — you’re piping through a pty (pseudo-terminal), which is itself a file (/dev/pts/0, /dev/pts/1…).
The one-line memory hook: Terminal = window. Shell = interpreter. Kernel = gatekeeper. Think of it like: you speak English (terminal) → a translator (shell) → a bureaucrat who actually has access to the filing cabinet (kernel) → the filing cabinet (hardware).
This is the single most important map to memorize in Linux. Unlike Windows (C:\, D:\, E:\), Linux has one unified tree starting at / (called “root”). Everything — disks, USB drives, network shares, virtual devices — gets mounted somewhere inside this tree.
The Filesystem Hierarchy Standard (FHS) defines what goes where and why. It is maintained by the Linux Foundation. Knowing it means you always know where to find things — credentials, logs, configs, executables, libraries — whether you’re administering a server, forensicating a disk image, or post-exploiting a compromised system.
Modern distros (Debian 12+, Fedora, Ubuntu 22.04+) have merged /bin → /usr/bin, /sbin → /usr/sbin, /lib → /usr/lib. The old paths still exist as symbolic links. If you see ls -la /bin showing lrwxrwxrwx ... /bin -> usr/bin, that’s the merged layout. Older distros (and some embedded systems you’ll encounter on pentest engagements) still have separate /bin. Know both.
This is where general Linux knowledge becomes specifically cybersecurity knowledge. The following paths are targets, evidence sources, and attack vectors that appear repeatedly throughout this entire roadmap.
The x in /etc/passwd: In the old days, /etc/passwd stored actual password hashes in the second field. As the file needs to be world-readable (many programs consult it), having hashes there was a disaster. /etc/shadow was introduced to store hashes with restricted permissions (-rw-r----- root shadow). The x in the second field of /etc/passwd means “the hash is in shadow.”
Terminal window
# Compare permissions on these two files RIGHT NOW:
# -rw-r----- 1 root shadow 1203 Jul 23 2026 /etc/shadow ← only root & shadow group
The difference in those permissions is the entire philosophy of least privilege made concrete. Later chapters cover how to crack /etc/shadow hashes with John the Ripper and Hashcat once you have root or can read the file.
~/.ssh/known_hosts ← Hosts this user has connected to (OSINT goldmine)
/etc/ssh/sshd_config ← SSH server config (PermitRootLogin, PasswordAuthentication)
/etc/ssh/ssh_host_* ← Server's own host keys
In a post-exploitation scenario (you have a shell on a server), ~/.ssh/id_rsa is often your ticket to lateral movement. If the compromised user has an SSH key that’s been added to authorized_keys on other internal servers, you can pivot there without a password. This is an extremely common attack path in real engagements.
/var/log/apache2/ ← Apache access.log, error.log (web app attacks land here)
/var/log/nginx/ ← Nginx logs
/var/log/audit/audit.log ← auditd output — high-fidelity security events when enabled
/var/log/wtmp ← Binary log of all logins/logouts; read with `last`
/var/log/btmp ← Failed login attempts; read with `lastb`
/var/log/lastlog ← Last login per user; read with `lastlog`
Blue team usage:auth.log is the first place a SOC analyst checks after a suspected SSH brute force. A flood of “Failed password for root from 192.168.1.100” entries followed by “Accepted password for root” is a textbook breach indicator.
Red team usage: After gaining a foothold, skilled attackers clear or truncate logs: echo > /var/log/auth.log. More sophisticated attackers modify only the lines they care about. Log integrity monitoring (AIDE, Wazuh, Splunk) is specifically designed to catch this.
Writable web roots are how web shells get planted. If a file upload vulnerability lets you write a PHP file to /var/www/html/, you have code execution as the web server user (typically www-data). From there, privilege escalation is step two.
/proc is a virtual filesystem — the files in it don’t exist on disk. The kernel generates their content on the fly when you read them. This makes it invaluable for both system administration and hacking.
Terminal window
# See all running processes
ls/proc/# Every numbered directory is a PID
# What's a specific process doing?
cat/proc/1/cmdline|tr'\0'' '# Command line of PID 1 (systemd)
cat/proc/1/status# Process status: UID, GID, memory, threads
ls-la/proc/1/fd/# Open file descriptors (fd 0=stdin, 1=stdout, 2=stderr)
cat/proc/1/maps# Memory map of the process
# System information
cat/proc/cpuinfo# CPU model, cores, flags
cat/proc/meminfo# RAM usage, swap
cat/proc/version# Kernel version (critical for kernel exploit selection)
cat/proc/net/tcp# TCP connection table (hex; convert to find ports)
Security use: During privilege escalation, /proc is a goldmine. /proc/<pid>/environ may contain environment variables with API keys or passwords. /proc/<pid>/cmdline shows what command was run, sometimes including passwords passed as arguments. /proc/<pid>/fd/ may contain open file descriptors you can read even if the file was deleted from disk — this is how forensicators recover files from running processes.
Defenders watch /tmp closely. AIDE (filesystem integrity monitoring), auditd inotify watches on /tmp, and EDR products flag executable creation in /tmp as suspicious. Knowing this as an attacker means you either live without files (in-memory execution, covered in later chapters) or use more creative staging locations.
This is the single most important design principle of Unix/Linux, and understanding it deeply unlocks your intuition for how the system works — and how it can be abused.
In Linux, almost everything is represented as a file that you can read from or write to using standard I/O operations. This is not just a cute idea — it has deep architectural consequences.
# Read raw disk sectors — the entire disk as a byte stream:
ddif=/dev/sdaof=/tmp/disk.imgbs=512count=1# Read first 512 bytes (MBR)
# This is exactly what forensics tools do to image disks.
# Generate random data (for padding payloads, wiping files):
ddif=/dev/urandombs=1count=32|xxd
# /dev/urandom is the OS's cryptographic random number generator.
# Discard output (silence a command's output):
some-noisy-command2>/dev/null
# /dev/null: write to it → gone. Read from it → empty.
# The "black hole" of the filesystem.
Sockets as files:
Terminal window
# Docker's control socket — if you can read/write this, you own the host:
ls-la/var/run/docker.sock
# If a web app or script runs as a user with access to this socket,
# an attacker who compromises that app can escape the container.
# This is why "docker socket escape" is a real container breakout technique.
Proc entries as files:
Terminal window
# The kernel's routing table:
cat/proc/net/route
# The ARP cache:
cat/proc/net/arp
# TCP connections in hex (needs python to decode):
cat/proc/net/tcp
Named pipes for IPC:
Terminal window
# Create a named pipe:
mkfifo/tmp/mypipe
# In one terminal, write to it:
echo"hello from process A">/tmp/mypipe
# In another terminal, read from it:
cat/tmp/mypipe# blocks until data arrives
# Named pipes are how some backdoors create covert communication channels.
The attacker’s favourite abuse — /proc/pid/mem:
In some kernel versions and configurations, /proc/<pid>/mem can be written to by a process to modify another process’s memory. This is the mechanism behind some code injection techniques. Everything. Is. A. File.
Part 6: Absolute vs Relative Paths — More Than It Seems
Every file reference in Linux is either absolute or relative. This distinction seems trivial until you hit your first path traversal vulnerability or misconfigured cron job.
Path traversal vulnerabilities exist when a web application uses relative path logic without proper sanitization. If a PHP app does:
$file = $_GET['page'];
include("/var/www/html/pages/". $file);
An attacker requests: ?page=../../etc/passwd and the server includes /etc/passwd in the response. The double-dot sequences traverse up the directory tree. This is CVE category CWE-22 (Improper Limitation of a Pathname) and appears in thousands of real web apps.
Relative paths in cron jobs and scripts are another attack vector:
Terminal window
# A cron job runs as root and contains:
cd/tmp && ./cleanup.sh
# If an attacker can write to /tmp (world-writable!), they can put their own
# cleanup.sh there and get root code execution when cron runs.
Understanding absolute vs relative paths is prerequisite to understanding: path traversal, cron-based privilege escalation, SUID binary hijacking via PATH manipulation, and directory traversal in web apps.
Tools like AIDE (Advanced Intrusion Detection Environment) and Tripwire take cryptographic hashes of critical files at a known-good state and alert when they change:
Terminal window
# Typical AIDE config monitors:
/etc/passwdNORMAL# Alert if modified
/etc/shadowNORMAL
/etc/sudoersNORMAL
/bin/NORMAL
/sbin/NORMAL
/usr/bin/NORMAL
/var/log/GROWING# Expected to grow; alert on shrink or deletion
/tmp/DYNAMIC# Expected to change; but alert on SUID file creation
An attacker adding a backdoor to /etc/passwd (adding a root-level user) or replacing a system binary in /usr/bin/ gets caught by AIDE on the next scheduled check.
These rules create entries in /var/log/audit/audit.log for every matching event, including which user triggered it, from which process, and at what time. This is how enterprise Linux systems achieve compliance with SOC 2, PCI-DSS, and HIPAA audit requirements.
sudocommand# Run ONE command as root (requires your password + sudo rights)
sudo-i# Get a root shell (drops you into root's environment)
su-# Switch to root user entirely (requires root's password)
suusername# Switch to another user (requires that user's password)
Beginners often type sudo bash when they mean to escalate permanently, or try su and get confused when they don’t know root’s password (on Ubuntu, root has no password by default — use sudo -i).
/root is the home directory of the root user — equivalent to /home/alice for Alice. The root of the entire filesystem is /. These are completely different:
Terminal window
ls/root/# root user's home files (permission denied unless you're root)
ls/# the entire filesystem root — always accessible
Philosophy: Everything is a file. Disks, devices, kernel state, network connections — all accessible via standard read/write operations. This unifying model is what makes Linux so composable and so exploitable when misconfigured.
TryHackMe — Linux Fundamentals (Parts 1, 2, 3): Free rooms that put these concepts into interactive exercises on a real machine. Start here if you want guided practice: tryhackme.com/module/linux-fundamentals
OverTheWire — Bandit: A wargame that teaches Linux through CTF-style challenges. Level 0 is SSH access; each level teaches another filesystem/command concept. overthewire.org/wargames/bandit
VulnHub — Kioptrix Level 1: A vulnerable VM that starts with your knowledge of the filesystem. Great for applying day-1 skills immediately.
Run find / -perm /4000 -type f 2>/dev/null and list every SUID binary. Look each one up. (We’ll exploit these in depth in Chapter 12 — Linux Privilege Escalation Part 2.)
Read the man page for hier: man hier — the official FHS documentation, built into every Linux system.
Open /etc/passwd and decode every field of every line. Which accounts have /bin/bash as their shell? Which have /usr/sbin/nologin? What does nologin protect against?
Discussion
Questions, corrections, or something to add? Comment with your GitHub account.