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
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide