Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753446AbbGPEaa (ORCPT ); Thu, 16 Jul 2015 00:30:30 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:56758 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751830AbbGPEa2 (ORCPT ); Thu, 16 Jul 2015 00:30:28 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Andy Lutomirski Cc: "Serge E. Hallyn" , Seth Forshee , Alexander Viro , Serge Hallyn , James Morris , Linux FS Devel , LSM List , SELinux-NSA , "linux-kernel\@vger.kernel.org" References: <1436989569-69582-1-git-send-email-seth.forshee@canonical.com> <1436989569-69582-4-git-send-email-seth.forshee@canonical.com> <20150715214848.GA24204@mail.hallyn.com> <87wpy1camr.fsf@x220.int.ebiederm.org> Date: Wed, 15 Jul 2015 23:23:55 -0500 In-Reply-To: (Andy Lutomirski's message of "Wed, 15 Jul 2015 18:19:46 -0700") Message-ID: <87io9kzq5g.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 X-XM-AID: U2FsdGVkX19EB5P2sZey1BI7N61fBl8d001c8FY3KRs= 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.7 XMSubLong Long Subject * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 TVD_RCVD_IP Message was received from an IP address * 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 * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Andy Lutomirski X-Spam-Relay-Country: X-Spam-Timing: total 1290 ms - load_scoreonly_sql: 0.23 (0.0%), signal_user_changed: 6 (0.5%), b_tie_ro: 4.2 (0.3%), parse: 0.84 (0.1%), extract_message_metadata: 3.3 (0.3%), get_uri_detail_list: 1.52 (0.1%), tests_pri_-1000: 5 (0.4%), tests_pri_-950: 1.46 (0.1%), tests_pri_-900: 1.16 (0.1%), tests_pri_-400: 23 (1.8%), check_bayes: 21 (1.7%), b_tokenize: 7 (0.5%), b_tok_get_all: 7 (0.5%), b_comp_prob: 2.3 (0.2%), b_tok_touch_all: 2.9 (0.2%), b_finish: 0.80 (0.1%), tests_pri_0: 1235 (95.7%), tests_pri_500: 3.7 (0.3%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 3/7] fs: Ignore file caps in mounts from other user namespaces 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 Content-Length: 2620 Lines: 71 Ok. Andy I have stopped and really looked at your patch that is 4/7 in this series. Something I had not done before since it sounded totally wrong. That combined with your earlier comments I think I can say something meaningful. Andy as I read your patch the thread you are primarily worried about is chdir(/some/directory/in/another/mnt/ns). I think enhancing nosuid to deal with that case is reasonable, and is unlikely to break userspace. It is one of those hairy security things so we need to be careful not to introduce a regression. I think a top down enhancement of nosuid to just block funny cases that no one cares about is completely sensible. Removing goofy corner that no one cares about and that are only good for security exploits seems reasonable. I am a little concerned that smack does not seem to respect nosuid on filesystems. But that is an issue with nosuid not with your enhanced nosuid. Now this patch 3/7 really should be entitled: "Limit file caps to the userns of the super block". It really really is doing something different. This change is about a bottom up understanding of what file caps means on a filesystem mounted by a user namespace root. That is file caps should only apply to the user namespace root of the root user who mounted the filesystem, because that is all the privileges the mounter of the filesystem had. This guarantees that even if the filesystem somehow propagates with mount propagation that there will be no issues. I think I know how to make that happen... But deeply and fundamentally limiting a filesystem to only the privilieges of it's user namespace root, and enhancing nosuid protections are rather different things. The approaches show up differently for dealing with uids and gids, as mappings are required. The approaches will likely to continue to show up differently for file caps when Serge implements a version of file caps with a user namespace root in them. The approaches fundamentally will need to do different things with security xattrs. As mnt_may_suid can just treat as a filesystem without labels, while ultimately the lsms will have to do something meaningful. So while in the very narrow case of todays file caps the two approaches are the same. Enhancing nosuid is something very different from limiting a filesystem to it's mounters user namespace. Eric -- 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/