eCryptfs status and future
This session is about discussing the current status and issues with eCryptfs, and making a decision what needs to be done in order for it to be an appropriate install-time option in the LTS release.
Blueprint information
- Status:
- Started
- Approver:
- Jamie Strandboge
- Priority:
- High
- Drafter:
- Marc Deslauriers
- Direction:
- Approved
- Assignee:
- Tyler Hicks
- Definition:
- Approved
- Series goal:
- Accepted for precise
- Implementation:
-
Beta Available
- Milestone target:
- None
- Started by
- Marc Deslauriers
- Completed by
Whiteboard
Work items:
[tyhicks] fix mmap regression (data loss) https:/
[tyhicks] fix inode info race (kernel panic) https:/
[tyhicks] fix statfs() max filename length reporting https:/
[tyhicks] after ecryptfs_statfs() is fixed, test/review affected applications mentioned in bug 344878 and add bug tasks if they aren't using pathconf (1): TODO
[tyhicks] improve truncate path https:/
[tyhicks] improve logging (identify potential log fillers and rate limit or lower their log level) (1): TODO
[tyhicks] help get Thieu Le's full disk fixes upstream (3): DONE
[tyhicks] Add eCryptfs support to xfstests (medium) (1): POSTPONED
[tyhicks] Create control file for eCryptfs to use the various filesystem tests in autotest (medium) (1): POSTPONED
From etherpad:
http://
= Bug status =
* High priority bugs in stable releases
* mmap regression (data loss) https:/
* Inode info race (kernel panic) https:/
* pathconf
* Long filename bug https:/
* default on in installer when using encrypted home
* if unencrypted filename longer than 148 (or so) characters, end up larger then 255 chars encrypted
* constrained by restricted character set
* couple of options to fix:
* use indirect table via mapping file in directory - backups might miss it
* use xattrs - some backup utilities don't support this. could provide a tool to dump xattrs into a file for backup
* storing in the header (space contraned (8k)) - issues with links
* Need to fix since it is breaking desktop applications
* What are the current options for fixing?
* Should be more easily configurable at setup time
* Is filename encryption appropriate to ship as default in Ubuntu?
* possibly not
* behavior right now is different than what the user expects (eg we don't communicate ext4 is different than ext4+ecryptfs)
* backing out on new installs is a regression
* not encrypting filenames is unexpected
* enumerate applications that have the problems and fix them (add a bug task for each)
* launchpadlib
* evolution
* python-httplib2
* eclipse
* ...
* what if only encrypt short filesnames?
* not consistent
* Will these be fixed in in time for the LTS release?
* Other bugs that would be nice to fix
* Improve truncate path https:/
* Incredibly slow for growing files to a large size
* Currently uninterruptible
* Is sparse file support the right fix?
* can compare size with allocated
* leaks that the file has a hole
* applications that don't support sparse files will file it with zeros on copy
* tunable option that Ubuntu has on by default
* won't make merge window
* Out of storage space https:/
* fix pending review (should make merge window)
* Handle lower empty files https:/
* if file empty, turn it into ecryptfs file
= Near-term Improvements =
* Improve logging
* Many unnecessary messages are sent to the syslog, typically scaring users
* However, the messages are useful in debugging so eCryptfs needs a debugging
mode (dynamic debugging interface?)
* make tunable
* Encryption policy support (not for LTS)
* eCryptfs already does per-file encryption, so the next step is to have
some type of policy to determine what key should be used (user specific,
application specific, group specific, etc.)
* Policy language and compiler could take considerable time
= eCryptfs testing/maintenance =
* Acceptance criteria
* https:/
* need automated test suite
* Upstream -rc kernel releases typically get tested with fsx-linux, the Tuxera
POSIX Test Suite , and multi-job kernel builds inside eCryptfs mounts
* xfs-tests seem to be the preferred Linux filesystem test framework these days
* Add support for eCryptfs to xfs-tests?
* We need of more eCryptfs-specific testing, since it is somewhat unique in
design
* Regression tests, too
* What lower filesystems are we interested in supporting/testing?
* NFS? (no for LTS)
* btrfs? (possibly not a standard install option)
* Upstream testing
* traditionally just Ubuntu-like users
* need method to kickoff kernel tests easily
* userspace tests
* Ubuntu testing
* jenkins
* qrt?
* userspace tool to not rely on kernel to decrypt files
* enlist new developers
= Userspace =
* ecryptfs-
* ecryptfs-
* integrate with libguestfs
* how to make it a sort of 2 factor
* put wrapped passphrase somewhere else, which sort of helps if laptop stolen, can't decrypt
* key strengthen the user password, not the random mount passphrase. this needs a random salt if done
= Long-term Improvements =
* Unstack eCryptfs
* Most eCryptfs bugs are from the stacked filesystem architecture
* Merge main mount helper and encrypted home/private mount helper
* Eliminate duplicate code
* Could at least make it easy for users to manually mount their encrypted home
dir, using the main eCryptfs mount helper, in the near-term
* Separate mount helpers from complexity of placing key in kernel keyring
* ecryptfs-manager is a step in the right direction, but it needs some love
Wshilist
* policy per directory (application might want its own key. user too)
* could be done via mount args
* patches in development
HP's OpenStack deployment is using ecryptfs to encrypt /var/log for when disks are retired, moved, etc
* we now have a method to mount ecryptfs filesystems doing boot via system kernel key and tpm
* possibly interesting for Ubuntu in certain environments
