From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756773AbbGQARE (ORCPT ); Thu, 16 Jul 2015 20:17:04 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:51184 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755972AbbGQARA convert rfc822-to-8bit (ORCPT ); Thu, 16 Jul 2015 20:17:00 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Lukasz Pawelczyk 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 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> Date: Thu, 16 Jul 2015 19:10:34 -0500 In-Reply-To: <1437045404.2207.5.camel@samsung.com> (Lukasz Pawelczyk's message of "Thu, 16 Jul 2015 13:16:44 +0200") Message-ID: <87fv4nr6dh.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-AID: U2FsdGVkX18I7WCT50bYytDncRLVTd59OYWIjgtXaKY= X-SA-Exim-Connect-IP: 67.3.205.90 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] * 0.2 T_XMDrugObfuBody_14 obfuscated drug references X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Lukasz Pawelczyk X-Spam-Relay-Country: X-Spam-Timing: total 860 ms - load_scoreonly_sql: 0.23 (0.0%), signal_user_changed: 10 (1.1%), b_tie_ro: 7 (0.8%), parse: 1.09 (0.1%), extract_message_metadata: 12 (1.4%), get_uri_detail_list: 1.67 (0.2%), tests_pri_-1000: 4.8 (0.6%), tests_pri_-950: 1.30 (0.2%), tests_pri_-900: 1.10 (0.1%), tests_pri_-400: 24 (2.7%), check_bayes: 22 (2.6%), b_tokenize: 6 (0.7%), b_tok_get_all: 7 (0.8%), b_comp_prob: 2.7 (0.3%), b_tok_touch_all: 2.9 (0.3%), b_finish: 0.85 (0.1%), tests_pri_0: 264 (30.7%), tests_pri_500: 539 (62.7%), poll_dns_idle: 532 (61.9%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 0/7] Initial support for user namespace owned mounts X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Lukasz Pawelczyk writes: > On śro, 2015-07-15 at 16:06 -0500, Eric W. Biederman wrote: >> >> I am on the fence with Lukasz Pawelczyk's patches. Some parts I >> 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. >> >> 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 >> with >> the LSMs has been one of his challenges. > > I fail to see how those 2 are in any conflict. Like I said. They don't really conflict, and actually to really support 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 going 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 to 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 they > 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 out 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id t6H0H2hP011198 for ; Thu, 16 Jul 2015 20:17:02 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Lukasz Pawelczyk 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> Date: Thu, 16 Jul 2015 19:10:34 -0500 In-Reply-To: <1437045404.2207.5.camel@samsung.com> (Lukasz Pawelczyk's message of "Thu, 16 Jul 2015 13:16:44 +0200") Message-ID: <87fv4nr6dh.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Subject: Re: [PATCH 0/7] Initial support for user namespace owned mounts Cc: Serge Hallyn , linux-kernel@vger.kernel.org, Andy Lutomirski , Seth Forshee , linux-security-module@vger.kernel.org, Alexander Viro , selinux@tycho.nsa.gov, linux-fsdevel@vger.kernel.org List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: Lukasz Pawelczyk writes: > On śro, 2015-07-15 at 16:06 -0500, Eric W. Biederman wrote: >> >> I am on the fence with Lukasz Pawelczyk's patches. Some parts I >> 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. >> >> 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 >> with >> the LSMs has been one of his challenges. > > I fail to see how those 2 are in any conflict. Like I said. They don't really conflict, and actually to really support 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 going 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 to 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 they > 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 out 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