Cool file system tricks

Some file system tricks to help secure Unix.

Like many Unix tools and most system infrastructures, the file system portions of Unix are far more powerful then...

most people realize. Most of the basic tricks, like software RAID, mounting options such as "noexec" and splitting partitions up to prevent various attacks, are well known. However, this barely scratches the surface of what is possible.

Mounting file systems as read only, or as separate partitions can be exceedingly difficult as Unix systems must have access to certain directories and files very early in the boot process.

Mounting external file systems via network protocols such as NFS and iSCSI requires the network stack to be operational, which requires a large number of system libraries, startup scripts and configuration tools such as "ifconfig".

Fortunately, mount has a few tricks up it's sleeve.

Mounting file systems requires a directory to be present, such as /var or /bobs-stuff, however what most people do not realize it that on most Unix systems this directory need not be empty. This makes it possible to have an /etc directory with a minimal configuration needed to boot the system (such as the password as fstab files), which then has a file system containing the "real" /etc/ mounted overtop of it (with X configuration and all the other necessary components). This allows administrators to mount a new /etc at virtually any point in the boot process, early on using a local partition or later using a network file system. Of course, this introduces a number of management issues. While the underlying "stub" /etc/ directory is sparsely populated, what it does contain is quite critical and may need to be modified at some point. The simplest way to deal with this is to create another directory such as /etc-real/, and then create hardlinks to all the files in /etc/ using "ln". From there it is a simple task to modify the "stub" files as needed, however you will not be able to create any new files, and deleting old ones may be tricky. These methods can be used for virtually any important file system, from /etc/ to /var/, /usr/, /lib/ and so on.

Using local partitions for every major directory may not be possible due to the number of partitions required and the administrative issues of making the partitions large enough to accommodate future growth, but not large enough to waste space. Again, most Unix systems have a feature that solves most of these problems. Data files can be mounted as a file system, using "loopback" mounts. Simply create a large file (say 10 megabytes), mount it as a loopback device, format it, then mount it as a filesystem and you have a separate /sbin/ that is read only. On Linux (and other) systems, new files can even be mounted overtop old ones, thus the file system does not need to be unmounted (which can be difficult if it contains your /lib/ directory). The new file can then be copied over the old one at the next reboot, which may be an automated task if these files are pulled from the network.

So what is all of this good for?

You can distribute server "packages," for example on Linux:

cp /nfs-server/chrooted-packages/bind-9.2.1.img
losetup -e none /dev/loop0 /data/bind-9.2.1.img
mount /data/bind-9.2.1.img /var/named
/etc/rc.d/init.d/named start

You could even modify the named rc script to copy the file and mount it automatically whenever named is started. This technique works especially well for server farms running custom software or customized installations of software (i.e. Apache + specific PHP + other strange patches).

You can trivially build servers and refresh images, instead of installing Apache and several dozen support packages you copy one file and mount it as a directory and start the server. Recovering from intrusions is also simplified, the evidence is likely contained in the data file, which can easily be stored for later investigation, minimizing server downtime.

Please see the following manual pages for more information:

losetup for Linux
and this Web site for Solaris

About the author
Kurt Seifried is an Information Security Analyst with interests ranging from Microsoft and UNIX systems to network protocols and encryption (to name but a few). He has written a large number of articles (available online) and maintains many resources on his Website. He was formerly the senior analyst and main writer for SecurityPortal. Visit his site at

This was first published in September 2002

Dig Deeper



Find more PRO+ content and other member only offers, here.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:



  • Virtual desktop security guide

    To secure virtual desktops, consider antivirus, certificates and network vulnerabilities. Just remember, VDI doesn't always ...

  • Guide to low-cost desktop virtualization

    In this guide, learn to virtualize desktops without spending more than you would when deploying PCs, and what VDI vendors are ...

  • VDI pilot project guide

    A VDI pilot project should start with a VDI project plan. Know what pitfalls to avoid and test product options to achieve a ...