Mount options as a security layer

Most people think of security as the process of keeping their system software at its most recent version, keeping good passwords, and controlling access to their system. In reality there's many many things that make something "secure". When I decided to (or maybe coerced into) start this blog, my hope was to introduce people to the idea that every little bit helps. That no set "thing" was the gateway to a secure system. Instead, I wanted people to start considering the value of taking advantage of every chance for leverage.

"the general who wins a battle makes many calculations in his temple ere the battle is fought. The general who loses a battle makes but few calculations beforehand. Thus do many calculations lead to victory, and few calculations to defeat: how much more no calculation at all! It is by attention to this point that I can foresee who is likely to w in or lose." -Sun Tzu, the Art of War

One thing often thought of but rarely as a security leverage point are partition mounting options. The mount(8) command has a number of options that can be advantageous for such purpose. The following are non-filesystem dependent options that can be used to make a system less hospitable to intrusion.

noauto

Can only be mounted explicitly (i.e., the -a option will not cause the file system to be mounted).

nodev

Do not interpret character or block special devices on the file system.

noexec

Do not allow direct execution of any binaries on the mounted file system. (Until recently it was possible to run binaries anyway using a command like /lib/ld*.so /mnt/binary. This trick fails since Linux 2.4.25 / 2.6.0.)

nosuid

Do not allow set-user-identifier or set-group-identifier bits to take effect. (This seems safe, but is in fact rather unsafe if you have suidperl(1) installed.)

The idea here is to consider the role of the system and what ways you can segment the partitioning scheme to best take advantage of these options. Doing so will make the system non-standard and help to cause an intruder to spend time adjusting to the system. This time spent by the intruder is valuable time that you may have to better detect their presence. Additionally, some of these non-standard options render worms useless as they often depend on certain directories to behave in a certain way. For example, most worms in the wild assume they can read, write, and execute from /tmp. Don't let them.

Here's an example fstab for a multi-partition production system.

#                                                    
/dev/hda1               /boot           ext2      noauto,noatime             1 2
/dev/hda2               none            swap      sw                         0 0
/dev/hda3               /               ext3      defaults                   0 1
/dev/hda5               /tmp            ext3      nodev,noexec               0 1
/dev/hda6               /var            ext3      nodev,nosuid               0 1
/dev/hda7               /var/www        ext3      nodev,nosuid               0 1
/dev/hda8               /home           ext3      noatime,nodev,nosuid       0 1
/dev/hda9               /usr/portage    ext3      nodev,nosuid               0 1

# NOTE: The next line is critical for boot!
proc                    /proc           proc      nosuid                     0 0
shm                     /dev/shm        tmpfs     nodev,nosuid,noexec        0 0

In the example, /tmp cannot be used as a point of execution. As mentioned above, this breaks most attacks. It will also throw off the neophyte miscreant. The example also keeps some filesystems from being able to leverage the special bit upon execution. This is very useful to keep bit-preserving archives from being planted on the system and leveraged.

Some things to remember. Some options will break your system if applied to some directories.

/tmp - Some software depends on special bits being able to be set. This will often occur in /tmp.

/var/tmp/portage - Portage expects and needs to be able to build your system from this directory. If you deny execution for this directory as a mount point, you WILL break your system.

/? - There's likely others and, depending on your system, you will need to test any options you attempt. Make sure you don't attempt to make drastic mount changes when you don't have physical access to your system. It is possible to render your system un-bootable or unable to boot into run-level 3+ if you make mistakes.

The goal here is simple. Every little bit helps. If you can defeat the latest XML-RPC worm that you weren't aware you were vulnerable to just by breaking its expectation to use part of your system, then the time was well spent and your tactic successful.