linux-kernel - Re: [PATCH v14 2/5] overlayfs: check CAP_DAC_READ_SEARCH before issuing exportfs_decode

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-next>] [day] [month] [year] [list]

Message-ID: <CAOQ4uxh_K=p7z+qbkjSf_+hhVsw9xBuNc61dYnpkHFVUfxJaCw@mail.gmail.com>
Date:   Sun, 27 Oct 2019 09:24:52 +0200
From:   Amir Goldstein <amir73il@...il.com>
To:     Miklos Szeredi <miklos@...redi.hu>
Cc:     Mark Salyzyn <salyzyn@...roid.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        kernel-team@...roid.com, Jonathan Corbet <corbet@....net>,
        Vivek Goyal <vgoyal@...hat.com>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        overlayfs <linux-unionfs@...r.kernel.org>,
        linux-doc@...r.kernel.org,
        Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
        Jeff Layton <jlayton@...nel.org>,
        "J. Bruce Fields" <bfields@...ldses.org>
Subject: Re: [PATCH v14 2/5] overlayfs: check CAP_DAC_READ_SEARCH before
 issuing exportfs_decode_fh

+ ebiederm and nfsd folks

On Wed, Oct 23, 2019 at 11:08 AM Miklos Szeredi <miklos@...redi.hu> wrote:
>
>
>
> On Tue, Oct 22, 2019 at 10:46 PM Mark Salyzyn <salyzyn@...roid.com> wrote:
> >
> > Assumption never checked, should fail if the mounter creds are not
> > sufficient.
>
> A bit more explanation would be nice.  Like a pointer to the explanation given in the open_by_handle_at(2) code where this check was presumably taken from.
>

Well, it's not that simple (TM).
If you are considering unprivileged overlay mounts, then this should be
ns_capable() check, even though open_by_handle_at(2) does not
currently allow userspace nfsd to decode file handles.

Unlike open_by_handle_at(2), overlayfs (currently) never exposes file
data via decoded origin fh. AFAIK, it only exposes the origin st_ino
st_dev and some nlink related accounting.

I have been trying to understand from code if nfsd exports are allowed
from non privileged containers and couldn't figure it out (?).
If non privileged container is allowed to export nosubtreecheck export
then non privileged container root can already decode file handles...

Thanks,
Amir.