Why understanding the Linux Directory Structure is critical for System Security?

When diving into the world of Linux, one of the first things to understand is its particular directory structure. At first glance, it might seem like a maze of obscure folders. However, every directory serves a specific purpose, and understanding this structure is vital, not only for a efficient system administration tasks but also for maintaining a robust security.

Linux directories were slightly different in the past. But they have been meticulously standardized and refined over time and are still evolving. In this article I will take a deep dive into the historical reasoning behind the main root directories, explain the Filesystem Hierarchy Standard (FHS) initiative, and explore how this understanding can help fortify your system’s security.

Background and Historical Overview

How the Linux Directory Structure was designed?

The Linux directory structure is deeply rooted in the history of Unix. Early Unix systems, developed in the 1970s, had limited storage and memory. This led to the creation of a minimal and efficient directory layout that has influenced Linux’s organization to this day. Over time, as operating systems and technologies evolved, this structure was refined to balance simplicity, scalability, and security.

In Linux, as in Unix systems, there are basically two types of objects: Directories and Files. Actually, the directory itself is also a file, but intended to contain a catalog composed by names of other files. Files are organized within directories, which can also contain other directories, allowing to expand the directories structure similarly to the branches of a tree, but in a simple, scalable and organized way. In the nature, the base of the tree is the root. In Linux systems the base of directories is the root directory, in practice represented by “/”.

Do not confuse the root directory "/" with the home directory for the root user, usually mounted in "/root".

I just mentioned the word “mounted”, a very common word in the Linux terminology. In Linux, the storage devices are accessible to users trough directories. For this reason we usually say, for example, “the USB Drive is mounted at /mnt/external_drive”. I will use this term again later so now you are familiar with it.

Getting back to files and directories, here is an example of how directories and regular files are differentiated in the output of “ls -l” command.

ls -l /tmp/directory
drwxr-xr-x. 1 user group 60 31. Dez 23:59 /tmp/directory

ls -l /tmp/regular_file
-rw-r--r--. 1 user group 1 31. Dez 23:59 /tmp/regular_file

Note the prefix “d” for directory and “-” for a regular file.

The types of regular files in Linux can be text files, binary files, image files, audio files, video files, compressed files, archive files, database files, configuration files, metadata files, and device-specific data files.

Currently we have high capacity and fast disks accessible by reasonably small prices. Therefore, in the current days, if a server has multiple storage devices, the reason is more likely to increase performance and/or redundancy than to increase space. It was not the case in the past. As the Unix system was evolving, more programs and capabilities were included. Naturally the system itself and also the users demanded more space to settle the data . So, new storage devices were included on-demand and mounted in specific new or existing directories. In fact, this use case of “demand for more space” had a key influence in the current definition of the Main Root Directories, which I will better describe along the article.

We know that the two types of objects are Directories and Files, and that a storage device can be mounted in a directory. It is time to talk about special files.

What are the Unix/Linux special files?

In wider scope of a System it needs to interact with hardware. It should also make it easier for processes to interact with each other. It should also provide flexibility to users and processes to organize their information efficiently, for example, avoiding data duplication. All these and other use cases are fairly solved in Linux via special files. There are 6 types of special files in Linux.

1. Block Special Files

Block files provide buffered (or block-oriented) access to hardware devices like hard drives, SSDs, or USB drives. They allow reading and writing data in blocks.

ls -l /dev/sda1
brw-rw----. 1 root disk 259, 1 31. Dez 23:59 /dev/sda1

The file /dev/sda1 represents the first partition (1) of the first (a) SATA (s) hard drive (d). This file allows the system to read and write data to the partition in blocks.

Note the first letter on the line returned by "ls -l" command here and in the next examples. In this case, the letter "b" means the /dev/sda1 is a block file.

Practical Example

When you format or mount a hard drive, you’re interacting with a block device:

sudo mkfs.ext4 /dev/sda1   # Format the partition as ext4. Any existing information in /dev/sda1 will be lost after this command.
sudo mount /dev/sda1 /mnt  # Mount the partition on /mnt directory.

2. Character Special Files

Character files allow unbuffered access to hardware devices, meaning they read and write data byte by byte. These are used for devices like keyboards, mice, and serial ports.

ls -l /dev/ttyUSB0
crw-rw----. 1 root dialout 4, 64 31. Dez 23:59 /dev/ttyUSB0

This file represents a serial port on the system, typically used for serial communication with external devices.

Practical Example

You can interact with a serial device like this:

sudo screen /dev/ttyUSB0 9600  # Open a serial communication at 9600 baud rate

3. Named Pipes (FIFO)

A named pipe, also known as FIFO (First In, First Out), is used for Inter-Process Communication (IPC). It allows one process to write data and another to read it.

ls -l /home/user/.steam/steam.pipe
prw-------. 1 user group 0 31. Dez 23:59 /home/user/.steam/steam.pipe

Practical Example

A named pipe can be created using the mkfifo command:

mkfifo /tmp/my_fifo

One process writes to the pipe:

echo "Hello" > /tmp/my_fifo

Another process reads from it:

cat /tmp/my_fifo

4. Socket Files

Socket files are used for Inter-Process Communication (IPC), often across a network. They allow bidirectional communication between processes, either locally or over a network.

ls -l /var/run/docker.sock
srw-rw-rw-. 1 user group 0 31. Dez 23:59 /var/run/docker.sock

This is a Unix domain socket file used by Docker to allow the Docker CLI and Docker daemon to communicate.

Practical Example

By connecting to this socket, you can send commands to the Docker daemon:

sudo docker ps  # Communicates with Docker daemon via the socket

5. Symbolic Links (symlinks)

Symbolic links are special files that point to another file or directory. They act as shortcuts to the target file or directory.

ls -l /bin
lrwxrwxrwx. 1 root root 7 31. Dez 23:59 /bin -> usr/bin

Practical Example

A symbolic link can be created like this:

ln -s /srv/www /var/www

Now, accessing /var/www will actually refer to /srv/www.

6. Device Special Files

These are abstracted interfaces to hardware devices like hard drives, terminals, printers, etc. Linux uses these files, usually in the /dev directory, to interface with hardware.

ls -l /dev/null
crw-rw-rw-. 1 root root 1, 3 31. Dez 23:59 /dev/null

This special file discards all data written to it and returns nothing when read.

Practical Example

It is often used to discard unwanted output:

some_command > /dev/null  # Redirect output to /dev/null to discard it

Overview of Main Root Directories and Their Security Implications

Once you know about directories, regular files, and special files, also the root directory “/”, it is time to organize the System information. This is done though the Main Root Directories, which are explained below.

/bin, /sbin, /usr/bin and /usr/sbin: System Binaries

These directories store system binaries. While they all contain executable programs, they differ in purpose:

• /bin and /usr/bin: Contain binaries needed during boot and in single-user mode.
• /sbin and /usr/sbin: Hold binaries essential for system administration, typically reserved for the superuser.

The separation of these binaries enhances security by controlling access and limiting potential damage if a directory is compromised. Setting strict permissions on these directories is crucial to prevent unauthorized users from altering or adding malicious binaries.

Historic Facts

Interestingly, the existence of /usr/bin, as well the /usr/sbin, /usr/lib and /usr/tmp was to solve an out of space problem, as mentioned by Rob Landley . When the disk of the root filesystem was full, in order to make more space, some “not essential” programs were moved to the same disk where user information was stored, which was mounted at /usr. Later a third disk was included and mounted on /home. Consequently, the user data was moved from /usr to /home. This is why the user home directories are currently stored in /home and the reason the /usr remember us “user” but has not actually “user” data as intuitively expected.

Since that, for some time the content of /bin, /sbin, /lib and /lib64 was independent of their equivalents in /usr. But along the time this separation of binaries created compatibility issues among distros and also created some avoidable complexity to maintain scripts and tools. That was the motivation for the USB Merge Initiative which ensured that /bin, /sbin, /lib and /lib64 are currently symbolic links to their equivalents in /usr.

/etc: Configuration Files

The /etc directory is the nerve center of your system configuration. It contains configuration files for both the operating system and installed software. Securing /etc is critical, as unauthorized changes to configuration files can lead to system breaches or disruptions. Best practices include using proper file permissions and ensuring that only trusted users can modify sensitive configuration files.

Historic Facts

The name “etc” in the Linux file system originates from UNIX and stands for “et cetera”, which is a Latin phrase meaning “and other things.” Historically, the /etc directory was intended to store miscellaneous files, mainly configuration files, that did not fit elsewhere in the file system. Over time, its role became more formalized, and it is now specifically designated for system-wide configuration files. Despite this evolution, the original name remained as a nod to its historical roots.

There is also a claim that /etc stands for “extensive text configuration” or even “edit to configure”, but these are modern backronym (a retroactive creation of a meaning for an existing term) and are not historically accurate. The UNIX pioneers and documentation from the era make no mention of “extensive text configuration” or other possible backronyms. Instead, they clearly describe /etc as “et cetera” .

/var: Variable Data Files

The /var directory is home to log files, spool files, and other transient data. Logs stored in /var/log are particularly important for monitoring and auditing purposes. Protecting log integrity is essential for tracking suspicious activities. Security measures include setting proper access permissions, configuring log rotation, and securing logs against unauthorized deletion or tampering.

/home: User Data

The /home directory houses personal files for each user. By keeping user data separate from system files, Linux minimizes the risk of a user inadvertently compromising critical system areas. Proper access control and file permissions in /home ensure that users can access only their own data while protecting their privacy and the security of the system as a whole.

/tmp: Temporary Files

The /tmp directory is used for temporary file storage, accessible by all users. Because it’s writable by anyone, /tmp is a potential target for security risks like race conditions and symlink attacks . Implementing measures like the sticky bit (which restricts file deletion to the file’s owner) and regularly cleaning the directory can help mitigate these risks.

The Filesystem Hierarchy Standard (FHS) Initiative

There was a basic directory structure since the beginning of Unix, but the history also shows that some directories were created on demand and this was also the case after for a long time (maybe still valid). Since more distributions were created and new technologies were introduced, there was a demand to create a standard at least among the main root directories in order to maintain consistency across different Linux distributions.

The Filesystem Hierarchy Standard (FHS) was introduced and already updated some times to be aligned to context changes. The FHS is a set of guidelines that dictates how directories and their contents should be organized. This standardization not only makes it easier for users to switch between distributions but also ensures predictable paths and permissions, which are essential for securing a Linux system.

A less technical and more objective documentation about FHS can also be checked here .

Security Best Practices Linked to Directory Structure

With this context on how the Linux directories and files were designed, implemented, used, evolved and standardized we can talk about the most basic Security Best Practices linked to Linux Directories.

Implementing Role-Based Access Control (RBAC)

Understanding the directory structure is essential for implementing Role-Based Access Control (RBAC). RBAC helps you define user roles and restrict permissions according to the Principle of Least Privilege. By carefully assigning permissions to specific directories and files, you can prevent unauthorized access to critical system areas.

Hardening Specific Directories

Certain directories, like /usr and /etc, are critical for system integrity. Hardening these directories involves limiting write permissions and using tools like SELinux or AppArmor to enforce additional security policies. For example, ensuring that users cannot write to system binaries in /usr helps prevent privilege escalation attacks.

Auditing and Monitoring Critical Directories

Regularly auditing directories like /etc, /var, and /usr is crucial for maintaining security. Monitoring these directories for unexpected changes, unauthorized access, or unusual file modifications can help you detect potential breaches early. Implementing intrusion detection systems (IDS) and configuring log monitoring key strategies.

HINT: Some interesting tools to start exploring are audit and ossec.

Conclusion: The Role of Knowledge in System Security

Understanding the Linux directory structure is more than just a foundational skill—it’s a crucial element in maintaining a secure and reliable system. By grasping the purpose of main directories and implementing appropriate security measures, you can significantly reduce the risk of system compromise. In the end, security starts with knowledge, and knowing how your system is organized is the first step toward robust protection.

I hope my research and several years of experience working with Linux (and some adventures with other Unix-like operating systems) helped you to learn the most important concepts much faster than me. : )