Using CFS, the Cryptographic Filesystem

Oct 15, 2002 By Jerry Sweet

SysAdmin

A guide for installation and some benefits and cautions for using CFS for security.

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.

CFS vs. Other Tools

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).

Installing CFS

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).

______________________

Comments

cmkdir hangs

Submitted by David Gillies (not verified) on Tue, 05/03/2005 - 10:33.

This comment assumes a knowledge of C.

If you are finding cmkdir is hanging, you can patch the code yourself (cmkdir.c).

First add these header files

#include <sys/types.h> #include <sys/stat.h> #include <fcntl.h>

Next declare two new variables

int fd; unsigned char uc;

In cmkdir.c there are two places where the code is asking for random numbers. The first is at about line 160

for (i=0; i<32; i++) { ekey[i] ^= randbyte(); }

Alter this to read

fd=open("/dev/random",O_RDONLY); for (i=0; i<32; i++) { read(fd,&uc,1); ekey[i] ^= uc; } close(fd);

Then at about line 170 is a line that reads

*r = trand32();

Replace this with

fd=open("/dev/random",O_RDONLY); read(fd,&r,4); close(fd);

Then do make cfs again, copy the modified executable to its install directory, and you're good to go.

Re: Using CFS, the Cryptographic Filesystem

Submitted by Anonymous on Tue, 06/01/2004 - 01:00.

Notes on running CFS with Fedora Core 2:

cmkdir stops working. Apparently SIGALRM or something in the C library or kernel has changed such that the random number collection hangs for longer than I was willing to wait. I changed the code to use /dev/urandom; those who would like to wibble their mouse around for five minutes or more might consider /dev/random. Patches available on request from the sschaefer account at acm.org.

The mount command now defaults to tcp,vers=3, which doesn't work with cfsd, so your mount of /mnt/crypt (or /crypt) needs to look like

mount -o port=3049,intr,udp,vers=2 localhost:/null /mnt/crypt

Finally, I'm sad to say that the cfs-users e-mail list looks like it's gone: my attempts to subscribe to cfs-users-request@nsa.research.att.com only generated a refusal to relay.

Re: Using CFS, the Cryptographic Filesystem

Submitted by Anonymous on Wed, 10/16/2002 - 01:00.

You write:

"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."

I don't think that's right. I'm using loopback crypto with losetup using

aes encryption right now like this:

/sbin/losetup -e aes /dev/loop0 /dev/hdd5

mount /dev/loop0 /home

it also supports several other encryption methods. Here's the man page excerpt:

--encryption, -e encryption

enable data encryption. The following keywords are

recognized:

NONE use no encryption (default).

XOR use a simple XOR encryption.

aes use Advanced Encryption Standard encryption.

AES encryption is only available if you are

using the international kernel and AES

encryption has been enabled in the Crypto

API. enabled in the Crypto API.

blowfish

use Blowfish encryption. Blowfish encryption

is only available if you are using the

international kernel and Blowfish encryption

has been enabled in the Crypto API.

twofish

use Twofish encryption. Twofish encryption

is only available if you are using the

international kernel and Twofish encryption

has been enabled in the Crypto API.

cast5 use CAST5 encryption. CAST5 encryption is

only available if you are using the interna-

tional kernel and CAST5 encryption has been

enabled in the Crypto API.

DES use DES encryption. DES encryption is only

available if the optional DES package has

been added to the kernel. DES encryption

uses an additional start value that is used

to protect passwords against dictionary

attacks. Use of DES is deprecated.

des_ede3

use 3DES encryption. 3DES encryption is only