Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3003229imm; Thu, 24 May 2018 20:57:43 -0700 (PDT) X-Google-Smtp-Source: AB8JxZru/nU432XzycDIFc1Rs+kTg9JLHJgsAhijPp1UZl0IrqI3CP95VmckWLNYn5SzY7jT91Fh X-Received: by 2002:a17:902:206:: with SMTP id 6-v6mr834492plc.294.1527220663169; Thu, 24 May 2018 20:57:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527220663; cv=none; d=google.com; s=arc-20160816; b=Ng3OQzYQdtUJu4s+rOKi2lQ7Piqj14p5s41A0jeHBlKWSC9aFYtFMNjLyjZpGwpNbL HeSTA7VScAPSFtmgu8rE8k0mUJYn+BfCMuCGmm3OenkEAVbuy+8Q6jdr+mRw/WZU7D3X m1kA4OSsZiG4w+GOdA6UtrbszFV9YP93dbRma1f7j3ZZuiamxvo3vGHncSa+tjJfHPjz +SqkWWDwvMtD+VrB9CalM1PQ5mq592gngsKF0DaUX79F7iXJk12Ut6PXUfMPjazQzWAA Xcow0/nQYeImm9IhQwsE4+oTmv9LCa1sEeeele0vThABSWZPLVjRELUgbXFRCn6RAEzC Svsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=pIuMyGe6lLCTcsWVNeBsmsHweuHlpPZ1B+V/C6do0u4=; b=z6p1gG22idA6Wmd0tAleuI/36SKFA6KvAc567+lVdWik0kKNvAXIsl3eIS2+hZ2FUr maFORol26BLBD7U3/jbfc6JZQ45fXX7N4TtMJVzmThFfwEljJpmRW3OqIf4jWeotlyD1 GaFXUyClLjfSa3slFJAjMOMxO0BwAdbXWAOYUXJePfX7tFmg/3Ydj5uBQ6upp5WYpOtF YqQHsH4irgtWbwZOueHecbgiKCJjQQHCc4JFf1m4MeuSgM5dNPzb6jRS6DoKkS+JhZPb BzuAGvr0O9TTS7QS9X1PjqKX3DgW2NuAHo2ZbIrpMXpa+r/c6MLVgDoDEhzfaB4tMm2g vSwg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e16-v6si22476600pli.476.2018.05.24.20.57.28; Thu, 24 May 2018 20:57:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935155AbeEYD5V (ORCPT + 99 others); Thu, 24 May 2018 23:57:21 -0400 Received: from ipmail07.adl2.internode.on.net ([150.101.137.131]:41806 "EHLO ipmail07.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934254AbeEYD5T (ORCPT ); Thu, 24 May 2018 23:57:19 -0400 Received: from ppp59-167-129-252.static.internode.on.net (HELO dastard) ([59.167.129.252]) by ipmail07.adl2.internode.on.net with ESMTP; 25 May 2018 13:27:17 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1fM3qu-0002V9-AV; Fri, 25 May 2018 13:57:16 +1000 Date: Fri, 25 May 2018 13:57:16 +1000 From: Dave Chinner To: "Eric W. Biederman" Cc: "Theodore Y. Ts'o" , Linux Containers , linux-fsdevel@vger.kernel.org, Seth Forshee , "Serge E. Hallyn" , Christian Brauner , linux-kernel@vger.kernel.org Subject: Re: [REVIEW][PATCH 0/6] Wrapping up the vfs support for unprivileged mounts Message-ID: <20180525035716.GE10363@dastard> References: <87o9h6554f.fsf@xmission.com> <20180524214617.GG7712@thunk.org> <87y3g8y6x9.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y3g8y6x9.fsf@xmission.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 24, 2018 at 06:23:30PM -0500, Eric W. Biederman wrote: > "Theodore Y. Ts'o" writes: > > > On Wed, May 23, 2018 at 06:22:56PM -0500, Eric W. Biederman wrote: > >> > >> Very slowly the work has been progressing to ensure the vfs has the > >> necessary support for mounting filesystems without privilege. > > > > What's the thinking behind how system administrators and/or file > > systems would configure whether or not a particular file system type > > will be allowed to be mounted w/o privilege? > > The mechanism is .fs_flags in file_system_type. If the FS_USERNS_MOUNT > flag is set then root in a user namespace (AKA an unprivileged user) > will be allowed to mount to mount the filesystem. > > There are very real concerns about attacking a filesystem with an > invalid filesystem image, or by a malicious protocol speaker. So I > don't want to enable anything without the file system maintainers > consent and without a reasonable expecation that neither a system wide > denial of service attack nor a privilege escalation attack is possible > from if the filesystem is enabled. > > So at a practical level what we have in the vfs is the non-fuse specific > bits that enable unprivileged mounts of fuse. Things like handling > of unmapped uid and gids, how normally trusted xattrs are dealt with, > etc. > > A big practical one for me is that if either the uid or gid is not > mapped the vfs avoids writing to the inode. > > Right now my practical goal is to be able to say: "Go run your > filesystem in userspace with fuse if you want stronger security > guarantees." I think that will be enough to make removable media > reasonably safe from privilege escalation attacks. > > There is enough code in most filesystems that I don't know what our > chances of locking down very many of them are. But I figure a few more > of them are possible. I'm not sure we need to - fusefs-lkl gives users the ability to mount any of the kernel filesystems via fuse without us needing to support unprivileged kernel mounts for those filesystems. Cheers, Dave. -- Dave Chinner david@fromorbit.com