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: <3d354949-0051-3f3a-f8ac-8dd99e9adc0f@nod.at>
Date:   Wed, 30 Nov 2016 09:27:28 +0100
From:   Richard Weinberger <richard@....at>
To:     Eric Biggers <ebiggers@...gle.com>
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

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