From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [PATCH 0/7] Initial support for user namespace owned mounts Date: Thu, 16 Jul 2015 19:10:34 -0500 Message-ID: <87fv4nr6dh.fsf@x220.int.ebiederm.org> References: <1436989569-69582-1-git-send-email-seth.forshee@canonical.com> <55A6C448.5050902@schaufler-ca.com> <87vbdlf7vo.fsf@x220.int.ebiederm.org> <1437045404.2207.5.camel@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Casey Schaufler , Seth Forshee , 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 To: Lukasz Pawelczyk Return-path: In-Reply-To: <1437045404.2207.5.camel@samsung.com> (Lukasz Pawelczyk's message of "Thu, 16 Jul 2015 13:16:44 +0200") Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Lukasz Pawelczyk writes: > On =C5=9Bro, 2015-07-15 at 16:06 -0500, Eric W. Biederman wrote: >>=20 >> I am on the fence with Lukasz Pawelczyk's patches. Some parts I=20 >> liked >> some parts I had issues with. As I recall one of my issues was that >> those patches conflicted in detail if not in principle with this >> appropach. >>=20 >> If these patches do not do a good job of laying the ground work for >> supporting security labels that unprivileged users can set than Seth >> could really use some feedback. Figuring out how to properly deal=20 >> with >> the LSMs has been one of his challenges. > > I fail to see how those 2 are in any conflict.=20 Like I said. They don't really conflict, and actually to really suppor= t things well for smack we probably need something like your patches. At the same time a patch written without dealing with s_user_ns is goin= g to going to fail to take a lot of important details into account. Right now after fixing the mount namespace issues the top priority is t= o work through the details and get s_user_ns implemented. By that I mean some version of patch 1 of Seth's series. s_user_ns fundamentally changes how the concepts are represented in the kernel in a way that is easier to secure, and that fundamentally better matches things. And sigh. This review has shown we don't quite have all of the details worked out. > If your approach here is to treat user ns mounted filesystem as if th= ey > didn't support xattrs at all then my patches don't conflict here any > more than Smack itself already does. The end game if people developing smack choose to play, is to figure ou= t how to store your unmapped labels in a filesystem contained by a user namespace and a smack label namespace root. > If the filesystem will get a default (e.g. by smack* mount options) > label then this label will co-work with Smack namespaces. A default, but I don't know if it will be smack mount options that will give that default. The devil is in the details and there are a lot of details. Eric