Using CFS, the Cryptographic Filesystem
If you want to keep private your personal files, such as those containing phone numbers, correspondence or journals, you could keep them in a hidden directory named ~/.private with mode 0700, so only you could read the files. Are you chuckling yet? Then let's consider employing a stronger privacy technique: cryptography. Specifically, let's look at Matt Blaze's open-source Cryptographic Filesystem (CFS) for UNIX and Linux.
Briefly, CFS allows you to safeguard your files in encrypted form in a normal directory. By using a key (or password, if you will), you temporarily decrypt your files to clear-text form for the window of time in which you need to work with them.
CFS makes your clear-text files available to you via a local loopback NFS mount; the CFS documentation refers to this as an "attach". Modifications you make to your clear-text files then are reflected automatically in the encrypted versions. You end your CFS session with a "detach", which makes your clear-text files disappear until the next time that you attach them.
This article reports some of the benefits and methods of using CFS as of version 1.4.0beta2. Some handy tools for use with CFS also accompany this article; see the Resources section.
Other ways to improve your privacy with open source tools are available; there's TCFS, the Transparent Cryptographic Filesystem, and OpenSSL, among other tools. Here's a brief summary of the relative merits of some of them, including TCFS, CFS and OpenSSL:
CFS: runs in user space, and no kernel patches are required. CFS uses an ordinary NFS loopback (a local NFS export with a local mount) that may create some security worries. Use caution in exporting directories. CFS was developed on SunOS and BSDI, then ported to Linux and other OSes, which bodes well for its ongoing utility. CFS supports several choices of encryption algorithms.
TCFS: requires a Linux-specific NFS module or kernel configuration. The tighter kernel bindings and extended filesystem attribute requirements yield better security but, potentially, less portability.
OpenSSL: runs in user space, and no kernel patches are required. OpenSSL supports a wide variety of encryption methods, as well as support for hardware tokens. OpenSSL is available for Linux, MS Windows and other environments. OpenSSL handles encryption or decryption of only one stream or file at a time, as of version 3.4.
OpenSSH: apples and oranges. You might use OpenSSH in conjunction with the other tools, but OpenSSH is mainly for interactive session privacy, not stored data privacy.
Linux loop device mount: comes with Red Hat Linux. At this time, DES appears to be the only serious encryption method available for loop device mounts. It requires preparation of a fixed-size container file and either root privileges or user permissions on loop device files. See mount(8) and losetup(8).
A source RPM, cfs-1.4.0.beta2j-6.2a.src.rpm, is available with the other tools accompanying this article on the LJ FTP site; see the Resources section. The beta2j version of the RPM includes, in addition to the components of the base beta2: one more security patch for Linux; two Red Hat Linux-friendly setup scripts, cfs.init and cfs-setup; and two handy tools, decrypt and dpw.py. All of these are broken out separately for those of you disinclined to use RPMs. This RPM was tested on Red Hat Linux 6.2, 7.1 and 7.2.
Always consider searching for later versions of CFS in either RPM or tarball form, and check for security patches. CFS version 1.4.1 exists as of this writing (see the Resources section); it adds support for NetBSD but no new features or bug fixes.
NFS is a prerequisite for using CFS. Be very selective with whom you share your filesystem resources--don't export your root directory and everything below it to the whole world. Consider using a personal firewall to forbid external access to most service ports, especially the ports the NFS and RPC port mapper dæmons use, 2049 and 111 (TCP and UDP), respectively.
In the following examples of commands, prompts are shown in bold type. The # shell prompt indicates root privileges; $ is the prompt for ordinary (non-root) users of bash and Bourne shells. Make any appropriate adjustments for your choice of shell.
Install the CFS source RPM package with the usual RPM command as root:
# rpm -iv cfs-1.4.0.beta2j-6.2a.src.rpm
Afterward, build and install the CFS package as follows, again as root:
# cd /usr/src/redhat/SPECS
# rpm -bb cfs.spec
# cd ../RPMS/i386
# rpm -ivv cfs-1.4.0.beta2j.i386.rpm
If you have difficulties installing this particular RPM, by all means seek out and install a more suitable RPM or tarball of the CFS distribution. Adapt the value-added files accompanying this article (on the FTP site) to your own needs and tastes. In particular, note that some NFS set up is required. See the cfs-setup script accompanying this article or read Matt Blaze's document "CFS Installation and Operation" (see Resources).
The following instructions are suitable for use with Red Hat Linux 6.2, 7.1, 7.2, and 7.3; you may need to make some adjustments for your variant of Linux.
Make certain that NFS is running:
# ps auxww | grep rpc.mountd
If rpc.mountd isn't running, then crank up NFS:
# /etc/rc.d/init.d/nfs start
Then start the CFS dæmon, cfsd, by running its boot-time startup file as root:
# /etc/rc.d/init.d/cfsd start
As yourself, create a private notes directory and attach it. We'll demonstrate two ways of doing this:
The easy way uses the decrypt tool that accompanies this article (see the Resources section):
$ decrypt -init Key: (type your key here to create the private directory, and remember the key) Again: (type your key again here) Key: (retype your key to proceed with the attachment)The other way to create the private notes directory uses the native CFS cmkdir and cattach tools:
$ mkdir ~/cdata $ cd ~/cdata $ cmkdir notes Key: (type your key here and remember it for future use) Again: (type your key again here) $ cattach notes $LOGNAME-notes Key: (re-type your key)
(In the example above, the predefined environment variable $LOGNAME contains your login name. It's used in order to avoid name collisions, but feel free to substitute a simpler clear-text directory name.)
In both cases it may take a minute or two before the CFS dæmon (cfsd) makes available the clear-text directory, $LOGNAME-notes.
Next, create a test file in the attached clear-text directory, as follows:
$ pushd /mnt/crypt/$LOGNAME-notes
$ echo "Test." > test.txt
$ popd
End your CFS session, and see what transpired in the relevant directories:
$ cdetach $LOGNAME-notes
$ ls /mnt/crypt
$ ls -R ~/cdata
The listing of ~/cdata should show an obscured name for your test.txt file, such as 03fa2aa5242d5a741866a6605de1ae3b.
Re-attach the directory in order to verify that your test file is still there. Again, there are two ways to do that:
Here's the easy way, using decrypt:
$ decrypt Key: (retype your key)Here's the normal way, using the CFS tool cattach:
$ cd ~/cdata $ cattach notes $LOGNAME-notes Key: (retype your key)
Next, verify that your test file is still there:
$ cat /mnt/crypt/$LOGNAME-notes/test.txt
Now go in search of the documentation for CFS, which includes on-line man pages for the commands cmkdir, cattach, cdetach, cpasswd and others. The underpinnings of CFS are described well in Matt Blaze's papers, "CFS Installation and Operation" and "A Cryptographic Filesystem for Unix". Read these using nroff -ms /usr/doc/cfs*/notes.ms. Among other useful tidbits in these papers is a suggestion for speeding up CFS performance by modifying the NFS rsize and wsize mount options.
After that, look for the README file that accompanies this article (see the Resources section), and check out the decrypt and dpw.py tools. The decrypt script simplifies the management of your private directories with CFS. Try this command:
$ decrypt -help
The dpw.py tool provides a graphical user interface for searching a private file of passwords you maintain with decrypt. Run dpw.py and click the help button. The dpw.py tool requires the standard Python module Tkinter, among others.
CFS's strengths include certain kinds of error reduction or error prevention:
After working with your clear-text files, CFS doesn't require a separate re-encryption step, thus avoiding the problem of re-encrypting with the wrong key.
Revision control, at least with RCS, is less error-prone. In contrast, where files are individually decrypted with OpenSSL, accidentally checking-in the clear-text file would leave it exposed.
CFS supports an inactivity timeout so the clear-text file isn't accidentally left available for long periods of time. Be sure to use the timeout option (-i) with the cattach CFS command.
Vulnerabilities to consider when using CFS and some other privacy tools:
Keyboard snooping can expose your secret key when you type the key for encryption or decryption.
Privileged users (intruders or not) can snoop out your attached clear-text files through various means.
Your clear-text files may be exposed on the network in various ways. OpenSSH can help to some extent, but it's best to confine your use of CFS and OpenSSL to your unshared local host's directly connected console and keyboard and to confine your private data and clear-text attach points to your local host's filesystems.
Consider keeping some private files in separate private directories; that way, not everything can be compromised simultaneously.
When applying revision control tools to your private files, think carefully about how to keep your clear-text files exposed only temporarily, for example, in the face of CVS's directory copying approach. With CFS, consider using RCS in the clear-text attach directory, as in cd /mnt/crypt/mycleartext && co -l myjournal.
Matt Blaze's CFS documents more thoroughly examine CFS's security issues and design considerations.
We shouldn't delude ourselves that CFS alone is going to protect us if we attract the interest of tenacious snoopers or if we're careless with our network security. We should use CFS for the same reason that we lock our doors and secure our windows at home. It's not necessarily going to prevent the worst, but offering some obstacles may help to keep things safer, longer.
A mobile laptop computer running Linux likely would be a fabulous place to employ CFS. A laptop, being largely self-contained and unshared, offers fewer vulnerabilities when other practical security precautions are employed, such as erecting a personal firewall and disabling unnecessary network services. And in the event that your laptop is stolen, your CFS-encrypted private files most likely will remain unseen. Don't forget to back up.
On my wish list of desired improvements to the open-source version of CFS would be hardware security token support, perhaps borrowed from OpenSSL. Requiring a hardware security token ameliorates the problem of password exposure from keyboard sniffing, although not necessarily keystroke capture over time. Also desirable would be a port of CFS to MS Windows for use with multiboot hosts.
My thanks to Greg Hao and Claude Johnson for test-driving the CFS installation instructions and accompanying scripts on Red Hat Linux 7.x. Thanks also to Enrico Scholz for the base SRPM.
The files accompanying this article, including the cfs-1.4.0.beta2j CFS source RPM, decrypt, dpw.py, cfs-setup and README files.
The base SRPM from which the cfs-1.4.0.beta2j source RPM was created for this article (see previous item).
Blaze, Matt. "CFS Installation and Operation". 1997. This paper is available in the CFS documentation directory, nroff -ms /usr/doc/cfs*/notes.ms. Or look for notes.ms among the C source files, e.g. in /usr/src/redhat/BUILD/cfs*/.
Blaze, Matt. "A Cryptographic Filesystem for Unix". 1993. This paper also is available in notes.ms, along with the preceding paper.
Mauriello, Ermelindo. "TCFS: Transparent Cryptographic Filesystem". 1997. Available on Linux Journal's web site.
Matt Blaze's own CFS software distribution page. The latest release as of this writing is cfs-1.4.1, while the version described in this article is cfs-1.4.0beta2. Version 1.4.1 adds support for NetBSD but offers no new features or bug fixes. For Linux you may continue to use cfs-1.4.0beta2j.
www.openssl.org: home of OpenSSL
www.openssh.com: home of OpenSSH
Jerry Sweet is a system administrator and programmer in the USA.
email: cfs-tools@akamail.com
