All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Theodore Ts'o <tytso@mit.edu>,
	Amir Goldstein <amir73il@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Miklos Szeredi <miklos@szeredi.hu>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-fscrypt@vger.kernel.org,
	overlayfs <linux-unionfs@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Paul Lawrence <paullawrence@google.com>
Subject: Re: overlayfs vs. fscrypt
Date: Wed, 13 Mar 2019 09:44:33 -0700	[thread overview]
Message-ID: <20190313164432.GE703@sol.localdomain> (raw)
In-Reply-To: <20190313160616.GR2217@ZenIV.linux.org.uk>

On Wed, Mar 13, 2019 at 04:06:16PM +0000, Al Viro wrote:
> On Wed, Mar 13, 2019 at 11:16:33AM -0400, Theodore Ts'o wrote:
> > Actually, the original use was for ChromeOS, but the primary
> > assumption is that keying is per user (or profile), and that users are
> > mutually distrustful.  So when Alice logs out of the system, her keys
> > will be invalidated and removed from the kernel.  We can (and do) try
> > to flush cache entries via "echo 3 > /proc/sys/vm/drop_caches" on
> > logout.  However, this does not guarantee that all dcache entries will
> > be removed --- a dcache entry can be pinned due to an open file, a
> > process's current working directory, a bind mount, etc.
> > 
> > The other issue is negative dentries; if you try open a file in an
> > encrypted file, the file system won't even *know* whether or not a
> > file exists, since the directory entries are encrypted; hence, there
> > may be some negative dentries that need to be invalidated.
> > 
> > So a fundamental assumption with fscrypt is that keys will be added
> > and removed, and that when this happens, dentries will need to be
> > invalidated.  This is going to surprise overlayfs, so if overlayfs is
> > going to support fscrypt it *has* to be aware of the fact that this
> > can happen.  It's not even clear what the proper security semantics
> > should be; *especially* if the upper and lower directories aren't
> > similarly protected using the same fscrypt encryption key.  Suppose
> > the lower directory is encrypted, and the upper is not.  Now on a copy
> > up operation, the previously encrypted file, which might contain
> > credit card numbers, medical records, or other things that would cause
> > a GDPR regulator to have a freak out attack, would *poof* become
> > decrypted.
> 
> Just to make sure - you do realize that ban on multiple dentries refering
> to the same directory inode is *NOT* conditional upon those dentries being
> hashed, right?

Isn't this handled by d_splice_alias() already, by moving the old dentry to the
new name?

- Eric

  reply	other threads:[~2019-03-13 16:44 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-13 12:31 overlayfs vs. fscrypt Richard Weinberger
2019-03-13 12:31 ` Richard Weinberger
2019-03-13 12:36 ` Miklos Szeredi
2019-03-13 12:47   ` Richard Weinberger
2019-03-13 12:47     ` Richard Weinberger
2019-03-13 12:58     ` Miklos Szeredi
2019-03-13 13:00       ` Richard Weinberger
2019-03-13 13:00         ` Richard Weinberger
2019-03-13 13:24         ` Miklos Szeredi
2019-03-13 13:32           ` Richard Weinberger
2019-03-13 13:32             ` Richard Weinberger
2019-03-13 14:26             ` Amir Goldstein
2019-03-13 15:16               ` Theodore Ts'o
2019-03-13 15:30                 ` Richard Weinberger
2019-03-13 15:30                   ` Richard Weinberger
2019-03-13 15:36                 ` James Bottomley
2019-03-13 15:51                   ` Eric Biggers
2019-03-13 16:13                     ` James Bottomley
2019-03-13 16:24                       ` Richard Weinberger
2019-03-13 16:44                   ` Theodore Ts'o
2019-03-13 17:45                     ` James Bottomley
2019-03-13 18:58                       ` Theodore Ts'o
2019-03-13 19:17                         ` James Bottomley
2019-03-13 19:57                           ` Eric Biggers
2019-03-13 20:06                             ` James Bottomley
2019-03-13 20:25                               ` Eric Biggers
2019-03-13 21:04                                 ` James Bottomley
2019-03-13 22:13                                   ` Eric Biggers
2019-03-13 22:29                                     ` James Bottomley
2019-03-13 22:58                                       ` Eric Biggers
2019-03-13 16:06                 ` Al Viro
2019-03-13 16:44                   ` Eric Biggers [this message]
2019-03-13 19:19                     ` Al Viro
2019-03-13 19:43                       ` Eric Biggers
2019-03-13 15:30               ` Eric Biggers
2019-03-13 15:30                 ` Eric Biggers
2019-03-13 20:33               ` Richard Weinberger
2019-03-13 20:33                 ` Richard Weinberger
2019-03-13 22:26                 ` Eric Biggers
2019-03-13 22:26                   ` Eric Biggers
2019-03-13 22:42                   ` Richard Weinberger
2019-03-14  7:34                     ` Miklos Szeredi
2019-03-14 17:15                       ` [RFC] fscrypt_key_required mount option Richard Weinberger
2019-03-14 17:15                         ` Richard Weinberger
2019-03-14 17:15                         ` [PATCH 1/4] fscrypt: Implement FS_CFLG_OWN_D_OPS Richard Weinberger
2019-03-14 17:15                           ` Richard Weinberger
2019-03-14 17:15                         ` [PATCH 2/4] fscrypt: Export fscrypt_d_ops Richard Weinberger
2019-03-14 17:15                           ` Richard Weinberger
2019-03-14 17:15                         ` [PATCH 3/4] ubifs: Simplify fscrypt_get_encryption_info() error handling Richard Weinberger
2019-03-14 17:15                           ` Richard Weinberger
2019-03-14 17:15                         ` [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required Richard Weinberger
2019-03-14 17:15                           ` Richard Weinberger
2019-03-14 17:49                           ` Eric Biggers
2019-03-14 17:49                             ` Eric Biggers
2019-03-14 20:54                             ` Richard Weinberger
2019-03-14 20:54                               ` Richard Weinberger
2019-03-14 23:07                               ` Theodore Ts'o
2019-03-14 23:07                                 ` Theodore Ts'o
2019-03-15  0:26                                 ` Unsubscribe Shane Volpe
2019-03-15  7:48                                 ` [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required Richard Weinberger
2019-03-15  7:48                                   ` Richard Weinberger
2019-03-15 13:51                                   ` Theodore Ts'o
2019-03-15 13:51                                     ` Theodore Ts'o
2019-03-15 13:51                                     ` Theodore Ts'o
2019-03-15 13:59                                     ` Richard Weinberger
2019-03-15 13:59                                       ` Richard Weinberger
2019-03-14 23:15                           ` James Bottomley
2019-03-14 23:15                             ` James Bottomley
2019-03-14 23:42                             ` Theodore Ts'o
2019-03-14 23:42                               ` Theodore Ts'o
2019-03-14 23:55                               ` James Bottomley
2019-03-14 23:55                                 ` James Bottomley
2019-03-13 15:01           ` overlayfs vs. fscrypt Eric Biggers
2019-03-13 15:01             ` Eric Biggers
2019-03-13 16:11             ` Al Viro
2019-03-13 16:33               ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190313164432.GE703@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=amir73il@gmail.com \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=paullawrence@google.com \
    --cc=richard@nod.at \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.