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:
Untar TCFS to create the directory /usr/src/linux/fs/tcfs which contains the code for TCFS and its related utilities.
Apply the tcfs.diff patch found in /usr/src/linux/fs/tcfs/patches to the kernel. Do this by changing directories to /usr/src and then typing patch < linux/fs/tcfs/patches/tcfs.diff.
Recompile the kernel. In the FileSystem section you will be asked about TCFS. It is possible to install tcfs as a module or built-in. In both cases it is necessary to recompile the kernel following the usual procedure.
Install the utilities. Once a kernel with TCFS support has been installed, change directory to /usr/src/linux/fs/tcfs/contrib/binaries where you will find the binaries for the TCFS utilities, and type make<\!s>install. It is also possible to compile the source code for the TCFS utilities located in /usr/src/linux/fs/tcfs/contrib/src.
Enable use of TCFS. The superuser of the client must generate a key for each user using the tcfsgenkey utility. This requires the user's password, so it must be done with the help of the user. The utility tcfsgenkey builds a database (/etc/tcfspasswd) where the keys used to encrypt files are stored. These are kept encrypted using the user's login password as key. In future releases of TCFS we are planning to provide support for smart cards, thus dispensing with the need of keeping the key (albeit in encrypted form) on the client.
TCFS utilities. The command mount provided by TCFS is capable of handling TCFS mount operations. We encourage you to use our version of mount in place of the standard mount command, since TCFS needs some information that the standard mount doesn't provide. To mount a file system with TCFS, type:
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
Webinar: 8 Signs You’re Beyond Cron
On Demand NOW
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.View Now!
|Chrome-Colored Parakeets||May 05, 2015|
|Mumblehard--Let's End Its Five-Year Reign||May 04, 2015|
|An Easy Way to Pay for Journalism, Music and Everything Else We Like||May 04, 2015|
|When Official Debian Support Ends, Who Will Save You?||May 01, 2015|
|May 2015 Issue of Linux Journal: Cool Projects||May 01, 2015|
|May 2015 Video Preview||May 01, 2015|
- Mumblehard--Let's End Its Five-Year Reign
- An Easy Way to Pay for Journalism, Music and Everything Else We Like
- When Official Debian Support Ends, Who Will Save You?
- Ubuntu Ditches Upstart
- "No Reboot" Kernel Patching - And Why You Should Care
- Video On Demand: 8 Signs You're Beyond Cron
- May 2015 Issue of Linux Journal: Cool Projects
- DevOps: Better Than the Sum of Its Parts
- Picking Out the Nouns
- Return of the Mac