TCFS(7)

NAME
tcfs - Transparent Cryptographic File System

DESCRIPTION
Recent advances in hardware and communication technologies have made possible and cost effective to share a file system among several machines over a local (but possibly also a wide) area network. One of the most successful and widely used such applications is Sun's Network File System.

NFS is very simple in structure but assumes a very strong trust model: the user trusts the remote file system server (which might be running on a machine in different country) and a network with his/her data. It is easy to see that neither assumption is a very realistic one. The server (or anybody with superuser privileges) might very well read the data on its local filesystem and it is well known that the Internet or any local area network (e.g, Ethernet) is very easy to tap.
Impersonification of users is also another security drawback of NFS. In fact, most of the permission checking over NFS are performed in the kernel of the client. In such a context a pirate can temporarily assign to his own workstation the Internet address of victim. Without secure RPC no further authentication procedure is requested. From here on, the pirate can issue NFS requests presenting himself with any (false) uid and therefore accessing for reading and writing any private data on the server, even protected data.
TCFS is a suitable solution to the problem of privacy for distributed file system. Our work improves on CFS by providing a deeper integration between the encryption service and the file system which results in a complete transparency of use to the user applications.

The TCFS 2.0 and above are implemented in kernel space and it works as the other filesystems in the VFS layer. This improves performances and transparency for the user. TCFS v2.0, and above, are available for Linux kernel 2.0.x and can work as a module using the new module support provided by 2.0 kernels generation.

Starting with release 2.0 , TCFS will allow to securely share files among the members of a group.
More info and technical papers could be found at the following URLs:
http://tcfs.dia.unisa.it
http://tcfs.dia.unisa.it/group-sharing.html
Coders are available at tcfs@mikonos.dia.unisa.it.
A mailing list is available at majordomo@mikonos.dia.unisa.it.

Client side
The client side of TCFS consists of the following programs: mount(8) (utility for mounting TCFS filesystems), tcfsadduser(1), tcfsaddgroup(1), tcfsrmuser(1), tcfsrmgroup(1), tcfsgenkey(1), tcfsputkey(1), tcfsrmkey(1), tcfsviewkey(1), passwd(1) (utilities for key management), and the kernel module that pushes TCFS features into the kernel. To enable use of TCFS for a user, an entry in the TCFS key database must first be created by the system administrator using tcfsadduser. The entry created does not contain the key, yet. Once the entry in the TCFS key database has been created, the user can generate a key for herself using the command tcfsgenkey. tcfsgenkey generates the encryption/decryption key for the user's files and adds the key encrypted with the user's login password to the user's entry in the TCFS key database. To set up a TCFS group, the system administrator have to first create a normal unix group and then execute tcfsaddgroup -g group -m <number of members> -t threshold To access her files on a TCFS filesystem, the user needs to push her key into the TCFS kernel module using the tcfsputkey command. To become an active member of a group, the user have to push her share of the key into the kernel by executing tcfsputkey -g group The module keeps for each keep a reference count (corresponding to the number of times the key/share has been pushed into the kernel) and a permanent flag. The command tcfsrmkey (tcfsrmkey -g group) decrements the reference count of the key/share and if the count reaches 0 and the permanent flag is clear the key/share is removed from the TCFS kernel module. The permanent flag can be set and cleared using options of the tcfsputkey command. Keys other than the one in the TCFS key database can be specified using options of the tcfsputkey command. The tcfsviewkey is used to show the user's key/share currently in the TCFS key database and the reference count and the permanent flag of the user's key/share currently used by the TCFS kernel module.

  The TCFS module
The TCFS module includes the code to handle the RPC generated by the VFS and the management of extended attributes. The RPC are syntactically compatible to the NFS RPC but the one relative to read, write and directory handling have been extended to perform security operations.

Each time a new inode is created, the extended attribute secure is tested. If the file is secure, then all successive read and write operation will be filtered through the encryption/decryption layer. If the bit is not set, the module will behave exactly as an NFS one.

TCFS module works under the VFS layer so it uses VFS buffer caches to improve performances.

Special handling is required for directories. In fact, a block of directory data cannot be entirely encrypted, otherwise the server file system consistency will be corrupted. For each directory inode we encrypt filenames but not the other fields. This strategy allows us to reuse the standard file system depend fsck command on server.

The Server Side
The server used to test our prototype runs Linux with NFS daemon to export an ext2 type file system. We only use five of the 32 bits reserved for the extended attributes provided by the ext2 file system.

#define TCFS_SECURE_FL 0x00000080

#define TCFS_SIZE_BITS 0x00000700

#define TCFS_GSHARED_FL 0x00000800

Unfortunately, the NFS RPC procedures for reading and setting file attributes have not been designed to handle extended attributes. To let our client code to interact with a standard NFS server software, we provide a daemon for the server side to perform this task. We defined a new RPC PROGRAM XATTRD which issues the necessary calls to ioctl to read and set the extended attributes on the server. To summarize we can say that the server side is constituted by a standard NFS server plus a new xattrd daemon for managing the extended attributes over NFS.

FILES
/etc/tcfspwdb     The TCFS key database
/etc/tcfsgpwdb    The TCFS group key database

SEE ALSO
nfs_intro(7), tcfsadduser(1), tcfsaddgroup(1), tcfsrmuser(1), tcfsrmgroup(1), tcfsgenkey(1), tcfsputkey(1), tcfsrmkey(1), tcfsviewkey(1), lsattr(1), chattr(1), xattrd(8), mount(8), passwd(1),

BUGS
None so far.

AUTHORS
G.Cattaneo, <cattaneo@dia.unisa.it>
G.Persiano, <giuper@dia.unisa.it>
E.Mauriello, <ermmau@tcfs.dia.unisa.it>
A.Cozzolino, <andcoz@tcfs.dia.unisa.it>
A.Celentano, <angcel@tcfs.dia.unisa.it>
A.Del Sorbo, <anidel@tcfs.dia.unisa.it>
R.Pisapia, <rafpis@tcfs.dia.unisa.it>