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]
Message-ID: <20160125203656.GB10638@ubuntu-hedt>
Date:	Mon, 25 Jan 2016 14:36:56 -0600
From:	Seth Forshee <seth.forshee@...onical.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	linux-bcache@...r.kernel.org, dm-devel@...hat.com,
	linux-raid@...r.kernel.org, linux-mtd@...ts.infradead.org,
	linux-fsdevel@...r.kernel.org, fuse-devel@...ts.sourceforge.net,
	linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Richard Weinberger <richard.weinberger@...il.com>,
	Austin S Hemmelgarn <ahferroin7@...il.com>,
	Miklos Szeredi <miklos@...redi.hu>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND v2 00/19] Support fuse mounts in user namespaces

On Mon, Jan 25, 2016 at 02:01:22PM -0600, Eric W. Biederman wrote:
> Seth Forshee <seth.forshee@...onical.com> writes:
> 
> > On Mon, Jan 04, 2016 at 12:03:39PM -0600, Seth Forshee wrote:
> >> These patches implement support for mounting filesystems in user
> >> namespaces using fuse. They are based on the patches in the for-testing
> >> branch of
> >> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git,
> >> but I've rebased them onto 4.4-rc3. I've pushed all of this to:
> >> 
> >>  git://git.kernel.org/pub/scm/linux/kernel/git/sforshee/linux.git fuse-userns
> >> 
> >> The patches are organized into three high-level groups.
> >> 
> >> Patches 1-6 are related to security, adding restrictions for
> >> unprivileged mounts and updating the LSMs as needed. Patches 1-2
> >> (checking inode permissions for block device mounts) may not be strictly
> >> necessary for fuseblk mounts since fuse doesn't do any IO on the block
> >> device in the kernel, but it still seems like a good idea to fail the
> >> mount if the user doesn't have the required permissions for the inode
> >> (though this is a bit misleading with fuse since the mounts are done via
> >> a suid-root helper).
> >> 
> >> Patches 7-14 update most of the vfs to translate ids correctly and deal
> >> with inodes which may have invalid user/group ids. I've omitted patches
> >> for anything not used by fuse - quota, fs freezing, some helper
> >> functions, etc. - but if these are wanted for the sake of completeness I
> >> can include them.
> >> 
> >> Patches 15-18 update fuse to deal with mounts from non-init pid and user
> >> namespaces and enable mounting from user namespaces.
> >> 
> >> Changes since v1:
> >>  - Drop patch for FIBMAP.
> >>  - Use current_in_userns in fuse_allow_current_process.
> >>  - Remove checks for uid/gid validity in fuse. Intead, ids from the
> >>    backing store which do not map into s_user_ns will result in invalid
> >>    ids in the vfs inode. Checks in the vfs will prevent unmappable ids
> >>    from being passed in from above.
> >>  - Update a couple of commit messages to provide more detail about
> >>    changes.
> >
> > Now that the merge window is over, I'm wondering whether it might be
> > possible to get some feedback on these patches this cycle?
> 
> Definitely.  Apologies for not giving you much feedback earlier.
> 
> I had been hoping this was the kind of thing I could just double check
> to be certain you weren't doing anything silly and just apply.  After my
> last round of looking at this I realized that for me to be comfortable
> with these patches I will have to give them very close scrutiny, and
> check every detail.
> 
> Unfortunatly last cycle I had failed to budget enough time to give these
> patches the close scrutiny they need.
> 
> From a high level I am still very much in favor of this approach and
> at least getting as far as safe unprivileged fuse mounts.
> 
> I have one or two little things to look at and then I hope to be going
> through your patches one by one in detail.

Great. Thanks Eric.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ