In closing, we'll mention two rather unusual ideas in filesystems. This information is provided partially for completeness, in the event that one of our readers has such a system. The second reason is to document some ideas we don't think helped security very much. We hope we don't encounter anything like them again any time soon.
Throughout this book, you will find that we often mention how the behavior of a command or action may be different if your version of UNIX is derived from BSD or AT&T UNIX . These differences are not so great as they once were, as SVR4 is the result of a merger of the majority of these two lines into one system.
However, in years gone by, the two systems were separate. This presented an interesting puzzle for some vendors who wanted to cater to both markets. Thus, someone came up with the idea of universes . The idea itself was fairly simple. Create a per-process "switch" in memory that would be set to either BSD or AT&T . The behavior of various system calls might depend on the value of the switch. Furthermore, certain special directories could be set up so that the directory you'd actually see would depend on the switch setting. Thus, you could have /usr/bin full of user programs, but it would really be two /usr/bin directories - one of BSD and one of AT&T !
Several companies adopted variations of the universe concept, including Pyramid, Apollo, Masccomp, and Sequent. In some of these systems, the switch from one environment to another was almost seamless, from the user's point of view. However, the scheme had several problems:
Also important to all of this was the problem of security. Often, clever manipulation of interactions between programs in the two universes could be used to break security. Additionally, a bug discovered in one universe was often mirrored in the software of the other, but usually only one got fixed (at first).
Eventually, everyone supporting a dual-universe system switched back to a single version of UNIX . Nevertheless, Solaris perpetuates some of these problems. For example, Solaris has two versions of the ls command, one in /usr/bin/ls , one in /usr/ucb/ls . It also has two versions of head , more , ln , ps , and many other commands. Thus, you need to check your search path carefully to know which version of a command you may be using.
To support diskless workstations, Hewlett-Packard developed a system called Context Dependent Files , or CDF . CDFS allow for multiple configurations to reside on a single computer. The goal of CDFS was to allow one master server to maintain multiple filesystems that will be viewed differently by different clients. This mechanism thus allows a single server to support a group of heterogeneous clients.
A CDF is basically a hidden directory whose contents are matched against the current context. HP explains it as follows:
CDFS are a powerful abstraction, but they were sometimes exploited by attackers. For example, the following sequence of commands will create a CDF directory:
% mkdir ./Hidden % chmod +H ./Hidden
This resulted in a directory that was normally invisible unless the -H option was used with the ls or find commands. A clever attacker could store all kinds of tools, stolen data files, and other interesting bits in such a directory. If the system administrator was not in the habit or was not trained to use the ls command with the -H option, then the directory might go unnoticed. The cracker could also find an existing CDF and store things in among the other files! As long as none of the filenames matched an existing context, they would probably never be noticed.
Even worse, tools the system administrator obtained for checking the system's overall security might not be aware of the -H flag , and not invoke it.
HP has dropped support for CDFS and moved to the use of NFS in version 10 of HP-UX, released in the spring of 1995. If you are not using version 10 or later, you should be sure to use the -H option on all ls and find commands!