linux-kernel - Re: [PATCH] fuse: Remove user_ns check for FUSE_DEV_IOC

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 12 Oct 2022 15:46:06 +0200
From:   Miklos Szeredi <miklos@...redi.hu>
To:     Jann Horn <jannh@...gle.com>
Cc:     Eric Biederman <ebiederm@...ssion.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fuse: Remove user_ns check for FUSE_DEV_IOC_CLONE

On Wed, 14 Sept 2022 at 16:27, Jann Horn <jannh@...gle.com> wrote:
>
> Commit 8ed1f0e22f49e ("fs/fuse: fix ioctl type confusion") fixed a type
> confusion bug by adding an ->f_op comparison.
>
> Based on some off-list discussion back then, another check was added to
> compare the f_cred->user_ns. This is not for security reasons, but was
> based on the idea that a FUSE device FD should be using the UID/GID
> mappings of its f_cred->user_ns, and those translations are done using
> fc->user_ns, which matches the f_cred->user_ns of the initial
> FUSE device FD thanks to the check in fuse_fill_super().
> See also commit 8cb08329b0809 ("fuse: Support fuse filesystems outside of
> init_user_ns").
>
> But FUSE_DEV_IOC_CLONE is, at a higher level, a *cloning* operation that
> copies an existing context (with a weird API that involves first opening
> /dev/fuse, then tying the resulting new FUSE device FD to an existing FUSE
> instance). So if an application is already passing FUSE FDs across
> userns boundaries and dealing with the resulting ID mapping complications
> somehow, it doesn't make much sense to block this cloning operation.
>
> I've heard that this check is an obstacle for some folks, and I don't see
> a good reason to keep it, so remove it.
>
> Signed-off-by: Jann Horn <jannh@...gle.com>

I see no issues with this.   f_cred seems to be unused by the VFS, so
this should have zero effect on anything other than rejecting or
allowing FUSE_DEV_IOC_CLONE.

Applied.

Thanks,
Miklos