In this section we cover advanced mount options and special situations. Some of the sections are optional.

The loop device

If you think of a mount as connecting an external device to the internal filesystem, then the loop device connects part of the internal filesystem back to the internal filesystem as if it was an external device. This is exactly the case. You can use the loop device to mount a filesystem image file (which is a filesystem contained in a file) as part of the filesystem so that you can access it. The common case is a CD or DVD ISO image. The loop device allows you to mount this image as if it was an actual CD/DVD device.

If you have an ISO image myiso.iso and an empty directory /mnt/iso for this purpose, for example,

The output of the mount command then shows the line

Restricting operations on a filesystem

One of the reasons we discussed for separating out the /tmp, /var, and /home filesystem is that each of these filesystems allow an unprivileged user to write unbounded amounts of data to it. Here's a silly simple example

Given enough time, this will fill up a filesystem. The only saving grace would be if /tmp were on a separate filesystem, in which case the system would continue to function, although /tmp would become crippled.

One way to limit this damage is to limit the maximum file size that a process can create using ulimit, but this could be bypassed by using multiple processes. The only bulletproof way to limit this is by the imposition of disk quotas. These can be imposed on a filesystem-by-filesystem basis, but very few Linux systems do so.

Since the /tmp directory may be accessible by the execution of a script from the Internet (since /tmp is world-writable and it is often the default desitination for downloads), it is wise to restrict these directories so that a program cannot be executed from them. If they are on separate partitions, this can be accompished by adding the noexec mount option. Of course, this also disallows valid users from executing programs from the /tmp directory, but there is probably no reason to need that.

Another option that is wise to include on many filesystems is the nodev option. When this is implemented, device files planted on the filesystem are unusable. There is really no reason that anyone should create a device file outside of /dev, and such hidden device files can be used without being noticed.

The last option that is wise to turn on on many filesystems is the nosuid option. Although it is not clear to me how an suid program could be created on one of these filesystems if it could not be created on the root filesystem, most filesystems should be restricted from set-user-id programs. Thus a recommended set of additional options for /tmp is noexec,nosuid,nodev

Also possibly susceptible to surreptitions modification is shared memory. Shared memory is mounted as a filesystem of type tmpfs from the fstab:

tmpfs                   /dev/shm                tmpfs   defaults        0 0

Once again, there is no reason to allow device, suid programs, or any programs from shared memory.

A wise sequence of steps to better securing your system would then be

• Replace /var/tmp with a symlink to /tmp
• Mount /dev/shm and /tmp with the nosuid,nodev,noexec mount options
• Mount all filesystems except / with the nodev option
  

You might be able to get a bit more restrictive that this, but restricting the [single] world-writable system temporary directory and shared memory is the most important

bind

Sometimes you would like a filesystem to be mounted in two places, rather than just one. In our previous example, we could have simply mounted the /tmp directory at /var/tmp instead of using the old-fashioned symlink method.

An existing directory can be cross-mounted at another directory using the bind mount option. In this case, the device position in the fstab (or mount command) is the source directory and the bind option is added to the mount options. To replace our symlink then, after deleting the symlink we could have used the following:

First, recreate /var/tmp with the correct permissions, etc and SELinux context

mkdir /var/tmp; chmod 1777 /var/tmp; chown root:root /var/tmp; restorecon -R /var/tmp

then bind /tmp to /var/tmp:

mount -o bind /tmp /var/tmp

This can be placed in the fstab as

/tmp   /var/tmp                none   defaults,bind        0 0

If /tmp has been mounted with the noexec option, so is /var/tmp, of course. (I believe all the options of the original mount apply. For example, it is not possible to write to an ISO file by binding it to another directory and using the rw option.)

bind cannot be used to circumvent certain restrictions on a filesystem, such as try to 'fool' a server that some data appears where it can access it when it doesnt. It may, however, only be SELinux that catches this.

acl and user_xattr defaults

These options control the availability of access control lists and extended attributes on a filesystem. They are acl/noacl and user_xattr/nouser_xattr. Maddeningly, whether these options are on by default depends on how the filesystem is created. If it is created during installation, these options are turned on by default (evidently the installer runs tune2fs to add them after the filesystem is made). If you create the filesystem yourself, you must fix the options or add them to the mount options later. (The use of tune2fs to add default mount options will be covered later.)

Once again, ACLs will not be enabled on a filesystem you create unless you add them.

NOTE: if you want to add an ACL to a directory that is a mount point, acls must be enabled on the filesystem the directory is on! In other words, if I want to add an ACL to the /junk directory and it is a mount point, the / directory must have acls enabled!

barriers

journal options

These options are beyond our scope and we will discuss them in-class if desired.