What is the impact of mounting /usr in read-only mode on RHEL ?

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux (RHEL) 5
  • Red Hat Enterprise Linux (RHEL) 6
  • Red Hat Enterprise Linux (RHEL) 7

Issue

  • We’re working on defining a standard RHEL 7 installation that we intend to deploy as a base for all our RHEL systems from development all the way to production. As a part of the definition we’re looking at securing the base os installation.
  • Whether we can change the mount option of the '/usr' filesystem to read-only mode or is it mandate to keep the default Red Hat partitioning guidelines of mounting it as read-write.
  • We understand that mounting /usr in read-only mode would add a layer of protection for critical system files but some of us believe that this additional protection will only be marginal as we will not allow direct root login (securetty , no root login in ssh), and our internally developed applications will not run as root, and we’ll run our systems with SELinux in enforcing mode.
  • Question 1 : Mounting /usr as read-only is substantial security improvement or marginal security improvement ?
  • Question 2 : What’s the impact for managing system (specifically os updates) with standard configuration management tools. Will it complicate automation of software deployment ?
  • Does /usr mounted as read-only have a ratio (additional security) / (implementation and manageability cost) > 1, if we consider a generic base OS that will be deployed in all environment ?

Resolution

  • Until RHEL 6, it was not recommended to have /usr as a separate partition. However, we may have it for RHEL 7. Below Knowledge Base will provide more information :
    Why is /usr not recommended as a separate partition in RHEL?

  • In RHEL 7, having /usr as a separate partition, allows for a much smaller root file system, enabling systems that can more efficiently share disk space, and systems that are easier to maintain, more flexible, and more secure. To lessen the impact of this change, the previous /bin directory is now a symbolic link to /usr/bin, /sbin to /usr/sbin, and so on.

  • By mounting /usr in read-only, below problems may be faced :

    1. While software updates, coupled with long-running processes that are keeping old, now deleted, files open. The files system cannot be made rw/ro until the space for those deleted files has been released. The status can be seen with lsof /usr | grep -i deleted, but there will be some deleted library files that won't show up.
    2. /usr can be mounted read-only only after a reboot (by include "ro/rw" in the options for /usr in /etc/fstab), or after restarting any currently running processes holding deleted files on /usr. Getting all those processes out of the way may require bringing the system down to rescue mode plus killing off any stray background processes that didn't get stopped automatically.

  • RHEL 7 implementation document doesn't recommend to mount /usr in read-only mode :
    Migration Planning Guide : File System Layout

  • As in this case, automation is paramount and it is not acceptable to log on the systems and issue mount –o remount,rw /usr, it is recommend not to mount /usr as read-only. We may have to hit this command very often for software updates/patches and may not make /usr read-only again, until killing all the processes related to /usr or finally a reboot.

  • Moreover, any system related changes done at runtime that has dependency on /usr, will not be committed. Kernel/system will throw errors for this.

  • So, to summarize, even though making /usr read-only has security benefits, at the same time it has huge drawback of manageability and therefore,
    (additional security) / (implementation and manageability cost) < 1

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments