In this lesson, you will learn how to restrict which users or processes can interact with specific mount points using Discretionary Access Control (DAC) and Mandatory Access Control (MAC).
Even after a filesystem is mounted, Linux allows you to refine who can read, write, or enter the data stored at that mount point. By default, mount points inherit permissions from their parent directory, but we can override these to harden our storage infrastructure.
Implementing DAC Controls
DAC relies on standard Linux permissions (User, Group, Other). Since a mount point is essentially a directory, you can change its ownership and mode immediately after mounting it to prevent unauthorized access.
For example, if you mount a sensitive data partition to /mnt/secure_data, you should ensure the root user is the owner and restrict access so only a specific group can interact with it:
# Set ownership to a specific administrative group
chown root:storage_team /mnt/secure_data
# Restrict permissions so others cannot even see the directory contents
chmod 750 /mnt/secure_data
By setting the mode to 750, you ensure that only the owner and the storage_team group can access the mount point, effectively shielding the underlying storage from general user interference.
Implementing MAC Controls
While DAC depends on user identity, MAC (such as SELinux or AppArmor) controls access based on security labels and process profiles. Even if a user has "read" permissions via DAC, a MAC policy can forbid their specific application from accessing the mount point entirely.
If you are using SELinux, you can label a mount point to ensure only specific services can interact with it. You would first mount the volume, then apply the context:
# Relabel the mount point to match a restricted security context
semanage fcontext -a -t httpd_sys_rw_t "/mnt/secure_data(/.*)?"
restorecon -Rv /mnt/secure_data
In this scenario, even if a standard user logs in, the SELinux policy will block them from accessing /mnt/secure_data unless their process is explicitly permitted to interact with the httpd_sys_rw_t label. By combining these layers, you create a "defense-in-depth" approach where storage security is enforced both by filesystem ownership and kernel-level security profiles.
Key Takeaway: Use DAC to restrict access by user/group ownership and MAC to enforce strict, policy-based access rules that override standard user permissions.