Linux Foundations: Filesystem Hierarchy, Permissions & the Process Model

The Linux Filesystem Hierarchy

Every Linux system organizes files into a single tree rooted at /, with a small set of directories that mean the same thing across distributions. Knowing what lives where is the first habit that transfers across every investigation in this module.

This layout is largely standardized across distributions through the Filesystem Hierarchy Standard, so the same investigative habits, checking /etc for config changes, /var/log for history, /tmp for staged files, transfer whether the host is running Debian, RHEL, or anything in between.

The Permissions Model

Every file and directory on a Linux system has an owner, a group, and a set of permissions for three categories of user: the owner, the owning group, and everyone else. Each category can be granted read, write, and execute, which for a file means view contents, modify contents, and run as a program, and for a directory means list contents, create or remove entries, and enter it.

The numeric form just adds up the bit values for each category (read = 4, write = 2, execute = 1), so 7 means all three, 5 means read and execute without write, and so on for owner, group, and other in that order.

The Process Model

Every running program on a Linux system is a process, and every process carries two identifiers that matter for investigation: a unique process ID (PID) and the process ID of whatever started it, its parent process ID (PPID). That parent-child chain is recorded for the life of the process.

Processes also move through a small set of states: running (actively executing or ready to), sleeping (waiting on an event or resource), stopped (suspended, usually by a signal), and zombie (finished executing but not yet cleaned up by its parent). None of these states require deep detail yet, just the vocabulary.

The parent-child relationship is one of the strongest anomaly signals on a Linux host. A web server process spawning a shell, for example, is not a state a normal request-handling path produces, and that mismatch between expected and actual parentage is often the first thing that stands out in an investigation. The process model gets a full chapter of its own later in this module, chapter 5.

Shell Basics

The shell is the program that reads commands and runs them. Bash is the default on most distributions, alongside zsh on some systems and the minimal sh used for portable scripting. Whichever shell is in use, a few primitives repeat everywhere.

Environment variables are the shell's way of passing configuration to the processes it starts, things like a search path or a locale setting get inherited by every child process automatically. Redirection and piping, > to overwrite a file with output, >> to append to it, and | to feed one command's output into another, are the basic building blocks of shell scripting.

Both legitimate administration and a lot of attacker tradecraft (covered in chapter 6) are built on these same primitives, so recognizing them here pays off well beyond this chapter.

How This Module Builds From Here

The rest of this module applies the vocabulary from this chapter to progressively deeper topics.

• Users, Authentication & Privilege: how accounts, groups, and privilege escalation actually work under the permissions model covered here.
• Logging and Syslog Analysis: reading and correlating the logs that live under /var/log.
• Persistence Mechanisms: how attackers use legitimate startup and scheduling paths to survive a reboot.
• Process and Network Internals: the full detail behind PID, PPID, process states, and how processes talk over the network.
• Shell Tradecraft and Detection: how the redirection and piping primitives from this chapter show up in real attacker activity.
• Container and Docker Security: how the filesystem and process model change (and don't) inside a container.
• Linux Incident Response and Hardening: pulling every earlier chapter together into a response and hardening workflow.