linux-kernel - Re: [RFD] Common userspace tool for fscypto

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 30 Nov 2016 16:00:35 -0500
From:   Theodore Ts'o <tytso@....edu>
To:     Richard Weinberger <richard@....at>
Cc:     Joe Richey <joerichey@...gle.com>,
        Michael Halcrow <mhalcrow@...gle.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>, kzak@...hat.com,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        Eric Biggers <ebiggers@...gle.com>,
        David Gstir <david@...ma-star.at>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        linux-f2fs-devel@...ts.sourceforge.net,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [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