Secure Mount Points in Unix

The primary way of interacting with a Unix machine is through its filesystem.
Thus, when an intruder has gained access to a system, it is desirable to
limit what he can do with the files available to him. One way to accomplish
this is with the use of restrictive mount options.
A mount option is a flag that controls how the file system may be accessed. It
is passed to the operating system kernel’s code when the file system is
brought online. Mount options can be used to prevent files from being interpreted
as device nodes, to disallow binaries from being executed, and to disallow the
SUID bit from taking effect (by using the nodev, noexec, and nosuid
flags). Files ystems can also be mounted read-only with the ro option.
These options are specified from the command line by running mount with
the -o flag. For example, if you have a separate partition for /tmp that is on
the third partition of your first IDE hard disk, you can mount with the
nodev, noexec, and nosuid flags, which are enabled by running the following
command:

# mount -o nodev,noexec,nosuid /dev/hda3 /tmp

An equivalent entry in your /etc/fstab would look something like this:

/dev/hda3 /tmp ext3 defaults,nodev,noexec,nosuid 1 2

By carefully considering your requirements and dividing up your storage
into multiple file systems, you can utilize these mount options to increase the
work that an attacker will have to do in order to further compromise your
system. A quick way to do this is to first categorize your directory tree into
areas that need write access for the system to function and those that don’t.
You should consider using the read-only flag on any part of the filesystem
where the contents do not change regularly. A good candidate for this might
be /usr, depending on how often updates are made to system software.
Obviously, many directories (such as /home) will need to be mounted as
read/write. However, it is unlikely that users on an average multiuser system
will need to run SUID binaries or create device files within their home
directories. Therefore, a separate filesystem, mounted with the nodev and
nosuid options, could be created to house the users’ home directories. If
you’ve determined that your users will not need to execute programs stored
in their home directories, you can use the noexec mount option as well. A
similar solution could be used for /tmp and /var, where it is highly unlikely
that any process will legitimately need to execute SUID or non-SUID
binaries or access device files. This strategy would help prevent the possibility
of an attacker leaving a Trojan horse in a common directory such as /tmp
or a user’s home directory. The attacker may be able to install the program,
but it will not be able to run, with or without the proper chmod bits.
binaries or access device files. This strategy would help prevent the possibility
of an attacker leaving a Trojan horse in a common directory such as /tmp
or a user’s home directory. The attacker may be able to install the program,
but it will not be able to run, with or without the proper chmod bits.

There are a number of ways that an attacker can circumvent these mount
restrictions. For example, the noexec option on Linux can be bypassed by
using /lib/ld-linux.so to execute binaries residing on a file system mounted
with this option. At first glance, you’d think that this problem could be remedied
by making ld-linux.so nonexecutable, but this would render all
dynamically linked binaries nonexecutable.
So, unless all of the programs you rely on are statically linked (they’re probably
not), the noexec option is of little use in Linux. In addition, an attacker
who has already gained root privileges will not be significantly hampered by
file systems mounted with special options, since these can often be
remounted with the -o remount option. But by using mount flags, you can
easily limit the possible attacks available to a hostile user before he gains
root privileges.