Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753302AbbGOVtS (ORCPT ); Wed, 15 Jul 2015 17:49:18 -0400 Received: from mail-ob0-f171.google.com ([209.85.214.171]:36045 "EHLO mail-ob0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753216AbbGOVtP (ORCPT ); Wed, 15 Jul 2015 17:49:15 -0400 Date: Wed, 15 Jul 2015 16:48:13 -0500 From: Seth Forshee To: "Eric W. Biederman" Cc: Casey Schaufler , Alexander Viro , linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov, Serge Hallyn , Andy Lutomirski , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/7] Initial support for user namespace owned mounts Message-ID: <20150715214813.GB76420@ubuntu-hedt> References: <1436989569-69582-1-git-send-email-seth.forshee@canonical.com> <55A6C448.5050902@schaufler-ca.com> <87vbdlf7vo.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87vbdlf7vo.fsf@x220.int.ebiederm.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3326 Lines: 67 On Wed, Jul 15, 2015 at 04:06:35PM -0500, Eric W. Biederman wrote: > Casey Schaufler writes: > > > On 7/15/2015 12:46 PM, Seth Forshee wrote: > >> These are the first in a larger set of patches that I've been working on > >> (with help from Eric Biederman) to support mounting ext4 and fuse > >> filesystems from within user namespaces. I've pushed the full series to: > >> > >> git://kernel.ubuntu.com/sforshee/linux.git userns-mounts > >> > >> Taking the series as a whole, the strategy is to handle as much of the > >> heavy lifting as possible in the vfs so the filesystems don't have to > >> handle weird edge cases. If you look at the full series you'll find that > >> the changes in ext4 to support user namespace mounts turn out to be > >> fairly minimal (fuse is a bit more complicated though as it must deal > >> with translating ids for a userspace process which is running in pid and > >> user namespaces). > >> > >> The patches I'm sending today lay some of the groundwork in the vfs and > >> related code. They fall into two broad groups: > >> > >> 1. Patches 1-2 add s_user_ns and simplify MNT_NODEV handling. These are > >> pretty straightforward, and Eric has expressed interest in merging > >> these patches soon. Note that patch 2 won't apply cleanly without > >> Eric's noexec patches for proc and sys [1]. > >> > >> 2. Patches 2-7 tighten down security for mounts with s_user_ns != > >> &init_user_ns. This includes updates to how file caps and suid are > >> handled and LSM updates to ignore security labels on superblocks > >> from non-init namespaces. > >> > >> The LSM changes in particular may not be optimal, as I don't have a > >> lot of familiarity with this code, so I'd be especially appreciative > >> of review of these changes and suggestions on how to improve them. > > > > Lukasz Pawelczyk proposed > > LSM support in user namespaces ([RFC] lsm: namespace hooks) > > that make a whole lot more sense than just turning off > > the option of using labels on files. Gutting the ability > > to use MAC in a namespace is a step down the road of > > making MAC and namespaces incompatible. > > This is not "turning off the option to use labels on files". > > This is supporting mounting filesystems like ext4 by unprivileged users > and not trusting the labels they set in the same way as we trust labels > on filesystems mounted by privileged users. > > The first step needs to be not trusting those labels and treating such > filesystems as filesystems without label support. I hope that is Seth > has implemented. > > In the long run we can do more interesting things with such filesystems > once the appropriate LSM policy is in place. Yes, this exactly. Right now it looks to me like the only safe thing to do with mounts from unprivileged users is to ignore the security labels, so that's what I'm trying to do with these changes. If there's some better thing to do, or some better way to do it, I'm more than happy to receive that feedback. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/