linux-kernel - Re: overlayfs vs. fscrypt

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, 13 Mar 2019 13:36:02 +0100
From:   Miklos Szeredi <miklos@...redi.hu>
To:     Richard Weinberger <richard@....at>
Cc:     linux-fsdevel@...r.kernel.org, linux-fscrypt@...r.kernel.org,
        overlayfs <linux-unionfs@...r.kernel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: overlayfs vs. fscrypt

On Wed, Mar 13, 2019 at 1:31 PM Richard Weinberger <richard@....at> wrote:
>
> Hi!
>
> overlayfs and fscrypt are not friends.
> Currently it is not possible to use a fscrypt encrypted directory as upper
> directory with overlayfs.
> The reason for that is, fscrypt implements ->d_revalidate().
>
> From fscrypt's point of view having ->d_revalidate() makes sense because it
> wants to hide/show encrypted filenames if someone loads or unlinks a key.
>
> On the other hand, overlayfs makes sure that the upper directory cannot
> change beneath it. Therefore it checks whether the upper directory is a remote
> filesystem by checking for ->d_revalidate() and refuses to mount if so.
>
> In my little embedded Linux world it is common to use both UBIFS and
> overlayfs. Now with UBIFS being encrypted using fscrypt, overlayfs is a
> problem.
> My current hack is not using fscrypt_d_ops in UBIFS. This works because on a
> typical embedded target you setup your crypto keys exactly once, right before
> you mount overlayfs in an initramfs.
>
> But I'm sure this problem will hit sooner or later users of ext4 and f2fs too.
> Therefore I'd like to discuss possible solutions.
>
> So far I see two options:
>
> 1. Get rid of ->d_revalidate() in fscrypt.
> Maybe we find a way to return a dentry via ->lookup() which is not cached at
> all and therefore no ->d_revalidate() is needed. If unreadable and encrypted
> filename lookups are slow, so what?
> AFAIU this approach is impossible in the current dcache design since it is not
> allowed to have more than one dentry to the same file.

I don't get it.  Does fscrypt try to check permissions via
->d_revalidate?  Why is it not doing that via ->permission()?

>
> 2. Teach overlayfs to deal with a upper that has ->d_revalidate().
> Given the complexity of overlayfs I'm not sure how feasible this is.
> But I'm no overlayfs expert, maybe I miss something.

I don't think it would be too complex.  But first I'd like to
understand exactly why fscrypt is (ab) using d_revalidate().

Thanks,
Miklos