From: Michael Halcrow <mike@halcrow.us>
To: linux-fsdevel@vger.kernel.org
Cc: Phillip Hellewell <phillip@hellewell.homeip.net>,
yoder1@us.ibm.com, mcthomps@us.ibm.com, emilyr@us.ibm.com
Subject: eCryptfs: Request for review
Date: Tue, 18 Oct 2005 14:38:11 -0500 [thread overview]
Message-ID: <20051018193811.GA11545@halcrow.us> (raw)
[-- Attachment #1: Type: text/plain, Size: 2797 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 481 bytes --]
next reply other threads:[~2005-10-18 19:41 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-18 19:38 Michael Halcrow [this message]
2005-10-18 19:59 ` eCryptfs: Request for review Greg KH
2005-10-19 15:36 ` Charles P. Wright
2005-10-19 19:00 ` Michael Thompson
2005-10-19 19:38 ` Charles P. Wright
2005-10-19 19:55 ` Michael Thompson
2005-10-19 21:02 ` Erez Zadok
2005-10-19 21:38 ` Badari Pulavarty
2005-10-21 21:44 ` Michael Thompson
2005-10-21 21:56 ` Shaya Potter
2005-10-21 22:49 ` Badari Pulavarty
2005-10-24 18:19 ` Michael Thompson
2005-10-26 20:05 ` Michael Thompson
2005-10-26 20:13 ` Anton Altaparmakov
2005-10-27 13:13 ` Charles P. Wright
2005-10-20 14:25 ` Charles P. Wright
2005-10-26 23:29 ` Michael Thompson
2005-10-27 13:12 ` Charles P. Wright
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051018193811.GA11545@halcrow.us \
--to=mike@halcrow.us \
--cc=emilyr@us.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mcthomps@us.ibm.com \
--cc=phillip@hellewell.homeip.net \
--cc=yoder1@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.