[f2fs-dev] [RFD] Common userspace tool for fscypto
Hi! Since file level encryption has more than one user, currently ext4, f2fs and soon ubifs it would be nice to have a single tool to control fscrypto from userspace. For ext4 we have already at least two tools, one as part of e2fsprogs and another one on github[0]. IMHO the latter one is much more user friendly and intuitive to use. I as unable to find the userspace tool for f2fs. That said, what about implementing such a tool as part of util-linux to control fscrypto? We (David and I) would volunteer. Thanks, //richard [0] https://github.com/gdelugre/ext4-crypt -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [RFD] Common userspace tool for fscypto
On Wed, Oct 19, 2016 at 4:35 AM, Richard Weinberger wrote: > Hi! > > Since file level encryption has more than one user, currently ext4, f2fs and > soon ubifs > it would be nice to have a single tool to control fscrypto from userspace. > > For ext4 we have already at least two tools, one as part of e2fsprogs and > another > one on github[0]. IMHO the latter one is much more user friendly and > intuitive to use. > I as unable to find the userspace tool for f2fs. > > That said, what about implementing such a tool as part of util-linux to > control > fscrypto? We (David and I) would volunteer. While discussing several changes we have staged for release (we're trying to minimize churn by batching a large set of format changes all at once), we've recently recognized this need on my team and were planning on starting work on exactly what you propose. > Thanks, > //richard > > [0] https://github.com/gdelugre/ext4-crypt -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [RFD] Common userspace tool for fscypto
On Wed, Oct 19, 2016 at 01:35:54PM +0200, Richard Weinberger wrote: > Hi! > > Since file level encryption has more than one user, currently ext4, f2fs and > soon ubifs > it would be nice to have a single tool to control fscrypto from userspace. > > For ext4 we have already at least two tools, one as part of e2fsprogs and > another > one on github[0]. IMHO the latter one is much more user friendly and > intuitive to use. > I as unable to find the userspace tool for f2fs. > > That said, what about implementing such a tool as part of util-linux to > control > fscrypto? We (David and I) would volunteer. I have nothing against this plan (add to util-linux) if ext4, f2fs and ubifs guys agree too. Karel -- Karel Zak http://karelzak.blogspot.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [RFD] Common userspace tool for fscypto
On Mon, Oct 24, 2016 at 02:49:37PM +0200, Karel Zak wrote: > > That said, what about implementing such a tool as part of util-linux to > > control > > fscrypto? We (David and I) would volunteer. > > I have nothing against this plan (add to util-linux) if ext4, f2fs and > ubifs guys agree too. Our current plan is to implement it in e2fsprogs since we can more quickly iterate over code reviews and code improvements. At some future point I'm happy to transfer it over to util-linux much like we've done with blkid and uuid libraries and associated utilities. We'll probably also keep a version in e2fsprogs for the long term just because upstream e2fsprogs is now integrated into the Android's AOSP build infrastructure, and it's probably simpler keep the tool there than to try to add Android.mk files and add the necessary helper scripts to deal with the fact (a) in the AOSP build system, you have to be able to cross-compile packages using Linux, MacOS, and Windows as the host OS and (b) Android using the Bionic C library instead of glibc. In answer to Richard's other questions, of course it would be released under the GPL, and our goals for creating a new fscrypto are (a) make it be more user-friendly, (b) support the new file-system level encryption features and new algorithms which Michael's team will be implementing, including a stronger string-to-key (password hashing) algorithm, new encryption modes, data integrity, etc), and (c) not have to be tied to backwards compatibility concerns with the e4crypt command. (Since we are just starting a new e2fsprogs 1.44 development cycle, we'll have plenty of time to experiment with the UI and make incompatible changes before 1.44 gets released and at that point I would want to lock down the any option names, etc., for long-term backwards compatibility.) I suspect we'll keep e4crypt around for a while, just because it's a handy debugging tool, and in general it's faster to add quick wrapper around ioctls for testing purposes than it is to be very thoughtful about creating a UI which is both friendly and able to support new features in a backwards compatible way. I also suspect we'll want to put most of the bits that could be usefully called from other C programs (e.g., Android's userspace stack, and libpam modules) and put it in a new libfscrypto library. Cheers, - Ted P.S. If anyone is ever interested in trying to make util-linux build using AOSP (which would be cool since every once in a while I wish I had some of the util-linux tools purely for debugging purposes, but it's a bunch of work and I've never had the time, plus I wasn't at all convinced Karel would be willing to accept such changes upstream for util-linux), see e2fsprogs's Android.mk files plus the script in util/gen-android-files. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [RFD] Common userspace tool for fscypto
Michael, On 19.10.2016 19:36, Michael Halcrow wrote: > On Wed, Oct 19, 2016 at 4:35 AM, Richard Weinberger wrote: >> Hi! >> >> Since file level encryption has more than one user, currently ext4, f2fs and >> soon ubifs >> it would be nice to have a single tool to control fscrypto from userspace. >> >> For ext4 we have already at least two tools, one as part of e2fsprogs and >> another >> one on github[0]. IMHO the latter one is much more user friendly and >> intuitive to use. >> I as unable to find the userspace tool for f2fs. >> >> That said, what about implementing such a tool as part of util-linux to >> control >> fscrypto? We (David and I) would volunteer. > > While discussing several changes we have staged for release (we're > trying to minimize churn by batching a large set of format changes all > at once), we've recently recognized this need on my team and were > planning on starting work on exactly what you propose. Can you please some details? Will it be GPL? Part of util-linux? What features does it have? I hope more than just being a wrapper to the ioctls(). Thanks, //richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [RFD] Common userspace tool for fscypto
Michael, On 19.10.2016 19:36, Michael Halcrow wrote: >> That said, what about implementing such a tool as part of util-linux to >> control >> fscrypto? We (David and I) would volunteer. > > While discussing several changes we have staged for release (we're > trying to minimize churn by batching a large set of format changes all > at once), we've recently recognized this need on my team and were > planning on starting work on exactly what you propose. Did this plan already materialize? :-) Thanks, //richard -- ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [RFD] Common userspace tool for fscypto
Joe, On 29.11.2016 22:42, Joe Richey wrote: > Hi Richard, > > I'm Joe Richey, and I work on Mike's team. We've been playing around > with a few design > ideas regarding a tool for managing filesystem encryption. After going > though some iterations > with Ted, we have a fairly good idea about where to head design wise, > and I'm working on a > design document for it. It's a bit preliminary at this point, but I > can share it if you want. > > Our goal is to have a finished doc by end of Q4 and then get your and > Jaegeuk's feedback. Thanks for your quick response! I hoped you had already some code, but having a decent design document is also nice. I'm eager to read it. Do you also plan to address d/page cache related issues? i.e. when two users are logged into the system user rw is able to see decrypted file names and contents in /home/dags/ if user dags installs a key and accessed a file. Or files in /home/dags/ are still readable even after user dags purged the key. The tool could play games with CLONE_NEWNS to hide directories. To provide a correct "logout" we could expose shrink_dcache_parent() to usespace such that the emerging tool can purge the key and flush the dcache on the encrypted directory. But I fear exposing shrink_dcache_parent() is not a good idea. :-) Just some random ideas... Thanks, //richard -- ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [RFD] Common userspace tool for fscypto
On Tue, Nov 29, 2016 at 10:59:28PM +0100, Richard Weinberger wrote: > > Do you also plan to address d/page cache related issues? > i.e. when two users are logged into the system user rw > is able to see decrypted file names and contents in /home/dags/ > if user dags installs a key and accessed a file. > As far as I know, there are no plans to make it possible for one user to see plaintext while another user sees ciphertext. Fundamentally, the dentry, inode, and page caches are shared systemwide. This cannot be changed by using namespaces; it can only be changed by doing something like an ecryptfs-style stacked mount where the plaintext and ciphertext are actually exposed by different filesystems. And it was a fundamental design goal of ext4 encryption to not do a stacked mount. So the expectation is that to restrict access by other users once a key has been provisioned, file permissions should be used. > Or files in /home/dags/ are still readable even after > user dags purged the key. If you revoke the key (with 'keyctl revoke') rather than unlink the key (with 'keyctl unlink') then it actually does appear to work currently. The difference is that revoking the key is a modification of the key, whereas unlinking the key is only removing a link to the key without affecting any links which the kernel may have internally or which userspace may have in other keyrings. Revocation (but not unlinking) is detected by fscrypt_get_encryption_info() when someone tries to open an encrypted file or directory. There's also a d_revalidate dentry operation which cause a dentry to be invalidated if it's a plaintext name but the directory key is no longer valid, or if it's a ciphertext name but the directory key is now valid. There is however still work needed to make key revocation interact sanely with ongoing filesystem operations. Eric -- ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [RFD] Common userspace tool for fscypto
On Tue, Nov 29, 2016 at 10:59:28PM +0100, Richard Weinberger wrote: > Thanks for your quick response! > I hoped you had already some code, but having a decent design document > is also nice. I'm eager to read it. To be clear, the design document which Joe is working on is only addressing a new way of transforming a password or passphrase into a key. Previouly, we used PBKDF2 using a per-file system salt. (Well, that's what e4crypt used. Android used a completely random key that was protected by the user's pin or passphrase --- possibly stored in ARM TrustZone on some handsets.) The goal is to come up with something that works well with single-signon (i.e., can be integrated into PAM), as well as removable storage devices and directories that are protected by some passphrase other than the user's login for those people who are especially security conscious. It should also handle the password change case. It probably won't cover key recovery initially (that's probably more of a V2 or V3 thing), but the design should accomodate that. > Do you also plan to address d/page cache related issues? > i.e. when two users are logged into the system user rw > is able to see decrypted file names and contents in /home/dags/ > if user dags installs a key and accessed a file. > > Or files in /home/dags/ are still readable even after > user dags purged the key. > > The tool could play games with CLONE_NEWNS to hide directories. > To provide a correct "logout" we could expose shrink_dcache_parent() > to usespace such that the emerging tool can purge the key and flush > the dcache on the encrypted directory. But I fear exposing > shrink_dcache_parent() > is not a good idea. :-) Right now, the best thing I can suggest is "echo 3 > /proc/sys/vm/drop_caches" in executed PAM module on when the user terminates their login session. If you're really paranoid, make sure all processes running under the user's pid are terminated with extreme prejudice first. We don't have a good solution for a high security directory (e.g., $HOME/bitcoin) where you want to drop its keys and cached data in the middle of a user login session today. The drop_caches solution doesn't work well on a time sharing system since it drops *all* caches. Also, if you have anything keeping pages or file descriptors, etc., pinned, the drop_cache solution won't address that either. I suspect any realistic solution will require changes that will need to be run by the Al Viro and the MM folks, and may require adding something like BSD's revoke(2) functionality. To be honest, this isn't a particularly high priority item at the moment for me or Michael's team at the moment, so if someone wants to work on it, feel free. As they say, high quality patches are always accepted. :-) Cheers, - Ted -- ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [RFD] Common userspace tool for fscypto
Eric, On 30.11.2016 01:04, Eric Biggers wrote: > On Tue, Nov 29, 2016 at 10:59:28PM +0100, Richard Weinberger wrote: >> >> Do you also plan to address d/page cache related issues? >> i.e. when two users are logged into the system user rw >> is able to see decrypted file names and contents in /home/dags/ >> if user dags installs a key and accessed a file. >> > > As far as I know, there are no plans to make it possible for one user to see > plaintext while another user sees ciphertext. Fundamentally, the dentry, > inode, > and page caches are shared systemwide. This cannot be changed by using > namespaces; it can only be changed by doing something like an ecryptfs-style > stacked mount where the plaintext and ciphertext are actually exposed by > different filesystems. And it was a fundamental design goal of ext4 > encryption > to not do a stacked mount. Well, we could over-mount /home/rw with an empty directory for every user except rw. > So the expectation is that to restrict access by other users once a key has > been > provisioned, file permissions should be used. > >> Or files in /home/dags/ are still readable even after >> user dags purged the key. > > If you revoke the key (with 'keyctl revoke') rather than unlink the key (with > 'keyctl unlink') then it actually does appear to work currently. The > difference > is that revoking the key is a modification of the key, whereas unlinking the > key > is only removing a link to the key without affecting any links which the > kernel > may have internally or which userspace may have in other keyrings. Revocation > (but not unlinking) is detected by fscrypt_get_encryption_info() when someone > tries to open an encrypted file or directory. There's also a d_revalidate > dentry operation which cause a dentry to be invalidated if it's a plaintext > name > but the directory key is no longer valid, or if it's a ciphertext name but the > directory key is now valid. Ahh, in my quick and dirty tests I've always used purge. Let me try revoke. :) BTW: This limitations needs to be clearly documented somewhere. Usually an user thinks that only she can access encrypted files... Thanks, //richard -- ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [RFD] Common userspace tool for fscypto
On Wed, Nov 30, 2016 at 09:27:28AM +0100, Richard Weinberger wrote: > > BTW: This limitations needs to be clearly documented somewhere. > Usually an user thinks that only she can access encrypted files... > > Thanks, > //richard For what it's worth, I've been making a few updates to the public design document for ext4 encryption based on what's actually upstream now: https://docs.google.com/document/d/1ft26lUQyuSpiu6VleP70_npaWdRfXFoNnB8JYnykNTg It still needs work, though. It doesn't really answer the questions about access control and key revocation, for example, and of course now the upstream code isn't actually ext4 specific anymore. At some point it might be nice to write some in-tree documentation for fscrypto, e.g. a file Documentation/filesystems/fscrypto.txt. Eric -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel