Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753458AbeAQO3q (ORCPT + 1 other); Wed, 17 Jan 2018 09:29:46 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:60090 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753337AbeAQO3k (ORCPT ); Wed, 17 Jan 2018 09:29:40 -0500 X-Google-Smtp-Source: ACJfBosdYQgZYCzofLGeAoZnw2/j2LChBRqccKg9YpHm9E+7fl/meg1MrpEhVBSY5ZTQLZ8D1xGY4A== Date: Wed, 17 Jan 2018 08:29:35 -0600 From: Seth Forshee To: Alban Crequy Cc: Dongsu Park , linux-kernel@vger.kernel.org, containers@lists.linux-foundation.org, "Eric W . Biederman" , Miklos Szeredi , Sargun Dhillon , linux-fsdevel@vger.kernel.org, Tejun Heo , David Herrmann , Tom Gundersen Subject: Re: [PATCH 08/11] fuse: Support fuse filesystems outside of init_user_ns Message-ID: <20180117142935.GA3723@ubuntu-xps13> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Wed, Jan 17, 2018 at 11:59:06AM +0100, Alban Crequy wrote: > [Adding Tejun, David, Tom for question about cuse] > > On Fri, Dec 22, 2017 at 3:32 PM, Dongsu Park wrote: > > From: Seth Forshee > > > > In order to support mounts from namespaces other than > > init_user_ns, fuse must translate uids and gids to/from the > > userns of the process servicing requests on /dev/fuse. This > > patch does that, with a couple of restrictions on the namespace: > > > > - The userns for the fuse connection is fixed to the namespace > > from which /dev/fuse is opened. > > > > - The namespace must be the same as s_user_ns. > > > > These restrictions simplify the implementation by avoiding the > > need to pass around userns references and by allowing fuse to > > rely on the checks in inode_change_ok for ownership changes. > > Either restriction could be relaxed in the future if needed. > > > > For cuse the namespace used for the connection is also simply > > current_user_ns() at the time /dev/cuse is opened. > > Was a use case discussed for using cuse in a new unprivileged userns? > > I ran some tests yesterday with cusexmp [1] and I could add a new char > device as an unprivileged user with: > > $ unshare -U -r -m sh -c 'mount --bind /mnt/cuse /dev/cuse ; cusexmp > --maj=99 --min=30 --name=foo > > where /mnt/cuse is previously mknod'ed correctly and chmod'ed 777. > Then, I could see the new device: > > $ cat /proc/devices | grep foo > 99 foo > > On normal distros, we don't have a /mnt/cuse chmod'ed 777 but still it > seems dangerous if the dev node can be provided otherwise and if we > don't have a use case for it. > > Thoughts? I can't remember the specific reasons, but I had concluded that letting unprivileged users use cuse within a user namespace isn't safe. But having a cuse device node usable by regular users at all is equally unsafe I suspect, so I don't think your example demonstrates any problem specific to user namespaces. There shouldn't be any way to use a user namespace to gain access permissions towards /dev/cuse, otherwise we have bigger problems than cuse to worry about. Seth