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]

Message-ID: <20161130000407.GB107713@google.com>
Date:   Tue, 29 Nov 2016 16:04:07 -0800
From:   Eric Biggers <ebiggers@...gle.com>
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,
        Theodore Ts'o <tytso@....edu>,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        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:
> 
> 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