Securing Filesystems with fstab Mount Options

1. Understanding the /etc/fstab File

Before we can harden filesystems, we first need to understand the tool we'll be using: the /etc/fstab file. Its name stands for "file systems table," and it's a configuration file that tells your Linux system which storage devices to mount automatically at boot, where to mount them, and how.

As the article explains, every line in /etc/fstab represents a filesystem and is organized into six specific fields:

1. Device: Identifies the storage device.
2. Mount Point: The directory in the filesystem where the device will be accessible.
3. Type: The filesystem format (e.g., ext4, xfs, swap).
4. Options: This is where the magic happens for hardening. It's a comma-separated list of rules for the mount.
5. Dump: An outdated flag for a backup utility called dump. This is almost always set to 0.
6. Pass: Controls the order of filesystem checks (fsck) at boot. 0 means no check, 1 is for the root filesystem, and 2 is for others.

A Critical Best Practice: Using UUIDs

How you identify the device in the first field is extremely important. While you can use device names like /dev/sdb1, this is not recommended. These names can change if you add or remove other drives, causing your fstab entry to fail and potentially preventing your system from booting.

The reliable and standard method is to use the Universally Unique Identifier (UUID), a permanent and unique "name" assigned to the filesystem itself.

To find a device's UUID, you'll use the command sudo blkid. You can then use this UUID in your /etc/fstab file like this: UUID=a1b2c3d4-e5f6-....

2. Hardening Filesystems with Mount Options

The fourth field, options, is where we apply our security policies. The default option, defaults, is a shorthand for a set of standard options, including rw (read-write), suid, dev, and exec. For hardening, we will often want to override these defaults with more restrictive settings.

Let's break down the most important security options and why they matter:

• nosuid: Disables the effect of setuid and setgid bits on executable files. A setuid binary runs with the permissions of the file owner (often root), not the user who executed it. This is a common vector for privilege escalation attacks. If an attacker can place a malicious setuid binary on a partition (like a user's home directory) and trick someone into running it, they could gain root access. The nosuid option completely prevents this on the mounted filesystem.
• nodev: Prevents the interpretation of character or block special devices. In Linux, devices (like your hard drive, /dev/sda) are represented as files. This option prevents a user from creating a device file on the mounted partition that could be used to access hardware directly, bypassing other security controls.
• noexec: Prohibits the execution of any binaries from the filesystem. This is an incredibly effective hardening technique. If a partition is meant only for data storage (e.g., user home directories, web server assets, backups), there is no legitimate reason to run programs from it. Using noexec on /home, for instance, prevents users from downloading and running potentially malicious scripts or programs from their own home directory.
• ro: Mounts the filesystem as read-only. This is the ultimate lockdown for data that should not change. It's perfect for partitions containing backups, archives, or critical system data that is only modified during updates.

By combining these, you can create a very secure mount. For example, a partition for user data that does not need to contain executable programs could be mounted with:

defaults,nosuid,nodev,noexec

3. The Safe Workflow for Editing /etc/fstab

Warning: An incorrect entry in /etc/fstab can prevent your system from booting. You must be very careful and always test your changes before rebooting.

Here is the safe, step-by-step process for adding or modifying an entry:

1. Back up the file: Before you open fstab, make a copy.

   sudo cp /etc/fstab /etc/fstab.bak
   

2. Get device information: Find the UUID of the partition you want to mount.

   sudo blkid /dev/sdXN # Replace with your device, e.g., /dev/sdb1
   

3. Create the mount point: If it doesn't already exist, create the directory where you'll mount the filesystem.

   sudo mkdir /data
   

4. Edit /etc/fstab: Add the new line with your chosen options. Use sudo nano /etc/fstab or your preferred editor. For a separate data partition, a hardened entry might look like this:

   # Data partition for user files
   UUID=YOUR-COPIED-UUID-HERE    /data    ext4    defaults,nosuid,nodev,noexec    0    2
   

5. Test without rebooting: This is the most important step. The command mount -a will attempt to mount everything listed in /etc/fstab that isn't already mounted. If there's a syntax error in your new line, this command will fail and report it immediately.

   sudo mount -a
   

   If you get an error, fix your /etc/fstab file and try again. If it runs without error, your syntax is correct.
6. Verify the mount: Check that the filesystem is mounted correctly and with the right options.

   mount | grep /data
   

   The output should show your device mounted on /data and include the options you specified (nosuid, nodev, noexec).

By following this process, you can safely edit /etc/fstab and avoid boot-time surprises.

Conclusion

You have now learned how to apply security policies at the filesystem level, a fundamental aspect of system hardening. By carefully choosing mount options in /etc/fstab, you can significantly reduce your system's attack surface.

Key Takeaways:

• The /etc/fstab file defines how storage devices are mounted at boot.
• Always use stable UUIDs instead of device names like /dev/sda1.
• The options field is used to control mount behavior and enforce security.
• Key hardening options are nosuid, nodev, noexec, and ro (read-only).
• Always follow a safe workflow: backup fstab, edit, and test with sudo mount -a before rebooting.

Preview of the Next Lesson:
We've hardened our system at the network, application, and filesystem layers. In our final lesson for this module, we will go even deeper to the heart of the operating system. We will learn how to configure kernel runtime parameters for security using sysctl, allowing you to tune the behavior of the Linux kernel itself to resist certain types of network attacks and improve overall system stability.