eCryptfs: Request for review

We are preparing to send eCryptfs to the LKML for inclusion in the -mm
tree, and we would like to solicit feedback from those in the
community who have an interest in Linux filesystems and cryptographic
applications. We are mainly interested at this point in comments that
might help us with VFS-related issues.

eCryptfs can be obtained from its SourceForge CVS repository:

http://sourceforge.net/projects/ecryptfs

cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ecryptfs login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ecryptfs co -P .

The code to perform the filesystem stacking is derived from Erez
Zadok's Cryptfs, which is one of the filesystems instantiated through
the FiST framework:

http://filesystems.org/

I presented eCryptfs at the 2004 and the 2005 Ottawa Linux
Symposium. The paper from this year's symposium starts on page 209 of
the first half of the proceedings:

http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf

I like to describe it as a sort of ``PGPFS''. It is stacked on top of
other filesystems. It aims to combine the flexibility of GnuPG
encryption with the transparency of a kernel service. Cryptographic
contexts (e.g., symmetric cipher identifier and encrypted session
keys) are stored in the first page of data in the file. This allows
the underlying encrypted files to be copied between domains with
unmodified userspace applications, and as long as the recipient has
the necessary credentials, he can access the contents of the files
transparently through eCryptfs.

The first release of eCryptfs (0.1) will support only mount-wide
passphrase mode. Some of the more advanced features, such as dynamic
PKI modules (allowing integration w/ GnuPG keyrings, TPM, and so on),
have been implemented and tested to some extent, but they are
cumbersome to deploy without more mature policy support. We have
disabled public key operation modes for the 0.1 release (also in
anticipation of better policy support in the future releases), but
more advanced users and developers are encouraged to experiment with
that code to their hearts' content.

eCryptfs is still a little rough around the edges (some behavior is
due to current needs for debugging), but it is pretty close to its
final form for the 0.1 release. There are known corner cases where it
breaks down right now, and we are chasing those bugs at the
moment. Please take a look at it and provide whatever feedback you
can.

Thanks,
Mike
.___________________________________________________________________.
                         Michael A. Halcrow                          
       Security Software Engineer, IBM Linux Technology Center       
GnuPG Fingerprint: 419C 5B1E 948A FA73 A54C  20F5 DB40 8531 6DCA 8769