TCFS: Transparent Cryptographic File System

To explain the mechanics of TCFS we will first review the working of NFS. NFS is a simple distributed file system that allows a file system server to export its file systems to several clients. Applications, running on a client, access the remote file system via the usual system calls. The client kernel checks to see whether the requested data is on a local file system or an NFS file system. In the latter case, the kernel issues a request to the server; for example, if the application needs to read a block from a file on a remote file system, the client operating system issues a read request to the server. The server, upon receiving a read request, reads the data from its local file system and sends it to the client, which then passes the data to the application. It is important to remember that NFS provides a minimal form of user authentication. The server receives from the client the uid of the user requesting the data and checks if that user is allowed to access the file containing the data. Thus, it is possible for a user to change his uid on the client (for example, the superuser of the client machine can use the command su to become any user) or to modify the NFS client so that a different uid is provided with the request.

When using TCFS, files can be stored in encrypted form on the server file system with a different encryption key for each user. The encryption key is provided by the user to the TCFS client through the tcfslogin utility. (A detailed description of the TCFS utilities appears below.) Reading a block of data from the server is achieved following the NFS protocol, with one important exception: once the requested block is received by the TCFS client, it is decrypted before being passed to the application. Similarly, a block of data written by an application is encrypted with the user's key before being passed to the TCFS server. During a read or write operation the user's encryption key never leaves the TCFS client, and data travels between server and client only in encrypted form. Moreover, this approach addresses the problems related to user authentication. While it is still possible for a user to impersonate the legitimate owner of a file, he will receive only encrypted data.

Set up your TCFS server just as you would an NFS server—by exporting the file system you wish to share with your clients. Usually this is done by editing the /etc/exports file and restarting the NFS daemons (rpc.mountd, rpc.nfsd).

Retrieve xattrd from the TCFS package. It can be found in the linux/fs/tcfs/contrib/xattrd directory of the TCFS distribution. Copy xattrd to the daemon directory, usually /usr/sbin, and add it to your rc files. For the Slackware distribution, edit the /etc/rc.d/rc.inet2 file to look like Listing 1. rc.inet2 File.

For Red Hat or any other distribution using the System V init script model, create a file in the rc directory (/etc/rc.d/init.d in Red Hat 4) for starting and stopping the xattrd daemon and make symbolic links in the rc\#.d directories to start it. In Red Hat you can do this using the tksysv script. For an example of building the xattrd rc scripts, see Listing 2. File for Building xattrd Script.

Now, reboot the system or run xattrd as root to prepare the server for TCFS. Notice that xattrd reads /etc/exports at startup and so if you change /etc/exports, you must restart xattrd. xattrd adds functionality to the NFS server and is not meant to be a replacement; therefore, it is possible to use the same server as both a TCFS server and an NFS server.

Installing TCFS on the client is somewhat more complex, since most of the work is performed by the client—the kernel must be rebuilt to support TCFS.

The TCFS distribution provides a tar file to be unpacked in the /usr/src directory. We assume that the kernel sources are in the /usr/src/linux directory (this is the standard for most Linux distributions). Install TCFS with the following steps:

mount -t tcfs server:/remotepath /localpath

TCFS also supplies the passwd command which is used to update the encryption key database. It acts like the standard passwd command, but also updates the tcfspasswd file after changing the password. Changing your password with the old passwd command will result in the wrong encryption key being extracted from /etc/tcfspasswd, and thus, in a complete loss of data.

After login, each user has to execute tcfslogin. Utility tcfslogin requests the user's login password to decrypt the encryption key and pushes the cipher key in the kernel module. To remove the key, the user must execute the utility tcfslogout, which needs a TCFS file system mounted to work. In future releases we plan to include support for PAM (Pluggable Authentication Module), making it unnecessary to input the login password twice.

The lsattr and chattr commands act just as they do in EXT2. The TCFS versions support a new flag, X, to enable encryption of files. You can change status of a file (encrypt or decrypt) by typing:

chattr $ <+|-> $X