-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1I have some time this year to work on an encrypted filesystem forLinux. I have surveyed various LUG's, tested and reviewed code forcurrently existing implementations, and have started modifying someof them. I would like to settle on a single approach on which tofocus my efforts, and I am interested in getting feedback from theLKML community as to which approach is the most feasible.

This is the feature wish-list that I have compiled, based on personalexperience and feedback I have received from other individuals andgroups:

- Seamless application to the root filesystem - Layered over the entire root filesystem - Unencrypted pass-through mode with minimal overhead - Files are marked as ``encrypted'' or ``unencrypted'' and treated accordingly by the encryption layer - Key->file association - As opposed to key->blkdev or key->directory granularity - No encryption metafiles in directories, instead placing that information into Extended Attributes - May break some backup utilities that are not EA-aware; may require another mode where encryption metadata is stored in a header block on the encrypted file - Directories can be flagged as ``encrypted-only'', where any new files created in that directory are, by default, encrypted, with the key and permissions defined in the directory's metadata - Processes may have encryption contexts, whereby any new files they create are encrypted by default according to the process' authentication - Make as much metadata about the file as confidential as possible (filesize, executable bit, etc.) - Pluggable encryption (I wouldn't mind using a block cipher in CTR mode) - Authentication via PAM - pam_usb - Bluetooth - Kerberos - PAM checks for group membership before allowing access to certain encrypted files - Rootplug-based LSM to provide key management (necessary to use LSM?) - Secret splitting and/or (m,n)-threshold support on the keys - Signatures on files flagged for auditing in order to detect attempts to circumvent the encryption layer (via direct modifications to the files themselves in the underlying filesystem) - Ad-hoc groups for access to decrypted versions of files - i.e., launch web browser, drop group membership by default (like capability inheritance masks) so that the browser does not have access to decrypted files by default; PAM module checks for group membership before allowing access (explicit user authorization on application access requests) - Userland utilities to support encrypted file management - Extensions to nautilus and konqueror to be able to use these utilities from a common interface (think: right-click, encrypted) - Distro installation integration - Transparent shredding, where the underlying filesystem supports it - Versioning and snapshots (CVS-ish behavior) - Design to work w/ SE Linux

These are features that have been requested, but are not necessarilyhard requirements for the encrypted filesystem. They are justsuggestions that I have received, and I am not convinced that they areall feasible.

There are several potential approaches to an encrypted filesystem withthese features, all with varying degrees of modification to the kernelitself, each with its own set of advantages and disadvantages.

- LSM-based - Is this even possible? Are the hooks that we need there?

- Modifications to VFS (stackable filesystem, like NCryptfs) - Very low overhead claimed by Erez Zadok - Full implementation not released - Key->directory granularity - Evicts cleartext pages from the cache on process death - Uses dcache to store attaches - Other niceties, but it's not released...

My goal is to develop an encrypted filesystem ``for the desktop'',where a user can right-click on a file in konqueror or nautilus andcheck the ``encrypted'' box, and all subsequent accesses by anyprocesses to that file will require authentication in order for thefile to be decrypted. I have already made some modifications to CFSto support this functionality, but I am not sure at this momentwhether or not CFS is the best route to go for this.

I have had requests to write a kernel module that, when loaded,transparently starts acting as the encryption layer on top of whateverroot filesystem is mounted. For example, an ext3 partition may haveencrypted files strewn about, which are accessible only after loadingthe module (and authenticating, etc.).

Any advise or direction that the kernel community could provide wouldbe very much appreciated.