From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753272AbbI0Tjk (ORCPT ); Sun, 27 Sep 2015 15:39:40 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:41147 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752943AbbI0TjK (ORCPT ); Sun, 27 Sep 2015 15:39:10 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Seth Forshee Cc: Alexander Viro , Casey Schaufler , Serge Hallyn , Andy Lutomirski , linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, James Morris , "Serge E. Hallyn" References: <1443039368-55445-1-git-send-email-seth.forshee@canonical.com> <1443039368-55445-7-git-send-email-seth.forshee@canonical.com> Date: Sun, 27 Sep 2015 14:30:58 -0500 In-Reply-To: <1443039368-55445-7-git-send-email-seth.forshee@canonical.com> (Seth Forshee's message of "Wed, 23 Sep 2015 15:16:06 -0500") Message-ID: <87oagnek25.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX18i+Xdp/TkUOVPNuo8ngUYtTKbVeNdukq8= X-SA-Exim-Connect-IP: 67.3.201.231 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 * 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 * [sa05 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Seth Forshee X-Spam-Relay-Country: X-Spam-Timing: total 846 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 4.9 (0.6%), b_tie_ro: 3.5 (0.4%), parse: 1.30 (0.2%), extract_message_metadata: 12 (1.5%), get_uri_detail_list: 2.1 (0.2%), tests_pri_-1000: 4.7 (0.6%), tests_pri_-950: 1.15 (0.1%), tests_pri_-900: 0.93 (0.1%), tests_pri_-400: 28 (3.3%), check_bayes: 27 (3.2%), b_tokenize: 8 (0.9%), b_tok_get_all: 9 (1.1%), b_comp_prob: 3.7 (0.4%), b_tok_touch_all: 3.3 (0.4%), b_finish: 0.99 (0.1%), tests_pri_0: 782 (92.4%), tests_pri_500: 6 (0.7%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH v4 6/7] Smack: Add support for unprivileged mounts from 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 Seth Forshee writes: > Security labels from unprivileged mounts cannot be trusted. > Ideally for these mounts we would assign the objects in the > filesystem the same label as the inode for the backing device > passed to mount. Unfortunately it's currently impossible to > determine which inode this is from the LSM mount hooks, so we > settle for the label of the process doing the mount. > > This label is assigned to s_root, and also to smk_default to > ensure that new inodes receive this label. The transmute property > is also set on s_root to make this behavior more explicit, even > though it is technically not necessary. > > If a filesystem has existing security labels, access to inodes is > permitted if the label is the same as smk_root, otherwise access > is denied. The SMACK64EXEC xattr is completely ignored. > > Explicit setting of security labels continues to require > CAP_MAC_ADMIN in init_user_ns. > > Altogether, this ensures that filesystem objects are not > accessible to subjects which cannot already access the backing > store, that MAC is not violated for any objects in the fileystem > which are already labeled, and that a user cannot use an > unprivileged mount to gain elevated MAC privileges. > > sysfs, tmpfs, and ramfs are already mountable from user > namespaces and support security labels. We can't rule out the > possibility that these filesystems may already be used in mounts > from user namespaces with security lables set from the init > namespace, so failing to trust lables in these filesystems may > introduce regressions. It is safe to trust labels from these > filesystems, since the unprivileged user does not control the > backing store and thus cannot supply security labels, so an > explicit exception is made to trust labels from these > filesystems. Hmm. > > Signed-off-by: Seth Forshee > --- > security/smack/smack.h | 8 +++++++- > security/smack/smack_lsm.c | 41 ++++++++++++++++++++++++++++++----------- > 2 files changed, 37 insertions(+), 12 deletions(-) [snip] > @@ -3475,14 +3492,16 @@ static void smack_d_instantiate(struct dentry *opt_dentry, struct inode *inode) > if (rc >= 0) > transflag = SMK_INODE_TRANSMUTE; > } > - /* > - * Don't let the exec or mmap label be "*" or "@". > - */ > - skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp); > - if (IS_ERR(skp) || skp == &smack_known_star || > - skp == &smack_known_web) > - skp = NULL; > - isp->smk_task = skp; > + if (!(sbsp->smk_flags & SMK_SB_UNTRUSTED)) { > + /* > + * Don't let the exec or mmap label be "*" or "@". > + */ > + skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp); > + if (IS_ERR(skp) || skp == &smack_known_star || > + skp == &smack_known_web) > + skp = NULL; > + isp->smk_task = skp; I have to stop and ask is this really what we want to do? If I have permission I can get around this by explicitly setting the XATTR_NAME_SMACKEXEC. Perhaps that does not matter but I think it is siginficant. We don't do any filtering on the the smk_mmap label. Given the policy as I understand it is to only honor labels that match smk_root would we not be better off allowing anything to be set and filtering the labels at use when SMK_SB_UNTRUSTED is set? Having three different policies depending on the kind of label concerns me. > + } > > skp = smk_fetch(XATTR_NAME_SMACKMMAP, inode, dp); > if (IS_ERR(skp) || skp == &smack_known_star || Eric