Received: by 10.192.245.15 with SMTP id i15csp1011683imn; Sat, 10 Mar 2018 19:11:18 -0800 (PST) X-Google-Smtp-Source: AG47ELuYb3Ng+WTu4gyOcichWOBZsYP2gG4DsJrw281pwTzNMDfXPiItMRrHXa7I3Em0diI9bsBP X-Received: by 10.101.73.197 with SMTP id t5mr3099304pgs.426.1520737878835; Sat, 10 Mar 2018 19:11:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520737878; cv=none; d=google.com; s=arc-20160816; b=VVitdiSOcW3Z9cMP1YW2uilBgJlIZ/kxlU8pIFgysHlOy5oYsStMobqrYVm7iey+Ki 5jMiPT97u7EOiQ3PzesrsmxDjrQGtSN7vipK2uFVnAxerkPuYcJqmZgiaL5ZfZ30GFCN SeRSTRk9mE6Q7paSVvy5N913sm2bWN1R+LUIgtirrS6bIBev4WZH2LyFfbaGpI47AkfY 2bUTDKb07CwIB4rhS0utld5SFiUNMS0MqiHF+JWH4g5/qn0ujG0QPDk2t8p9DUtjylPB Mh7L1Z26/QHkHAylK3ydBFL+8EouxcaAjcE1qbevPA634mz5mA/tmg/vHyjzbC7m3K0m 17KA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=OiD2D6EqJtTSIfnjIlHHhhICSMKvl309AFHaaRuQ6NM=; b=UhfJAJqHQkyf1fAz2uB17CYBfqSYRDiNHfNW1bpNnGonO5m44eBBwZ1106YRyukJq/ pBFQAaXEv0kAJpYgF761gsZZ976uQTEPJcs3KEqNTPfBK/4dOxseqZoAmhwPbgIuXiM5 +FQ1maDk1D1kZq+V9C+4/vdwt+053zLFgD7pkRJfaVp1hk21ye0GyFO5z/2wde47iYQW x15or621URZqH4ZS5XTMVQ+EqunE3/ZPvhrouZzzzqH3WY8VCh+ZVZmiINyz8sy38cpt AiL3e5u56QpTDI/jfbiAMGyyTaFqPypjWGLaqBpcWRpJbdW/bSoiZ8b2wK8+8QgrPsLM mfOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cisco.com header.s=iport header.b=LNjvqbhu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=cisco.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3-v6si3756891plo.316.2018.03.10.19.10.17; Sat, 10 Mar 2018 19:11:18 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@cisco.com header.s=iport header.b=LNjvqbhu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=cisco.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751251AbeCKDHW (ORCPT + 99 others); Sat, 10 Mar 2018 22:07:22 -0500 Received: from rcdn-iport-9.cisco.com ([173.37.86.80]:30572 "EHLO rcdn-iport-9.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751223AbeCKDHU (ORCPT ); Sat, 10 Mar 2018 22:07:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5802; q=dns/txt; s=iport; t=1520737640; x=1521947240; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=YISdkcMBaBiTyDrigL70tCJt4SqCT9dKnaR/7HnVB2k=; b=LNjvqbhuzp0erFHYRX0/tn5lSOebYvRnnqwz7Ks3g9QZTRbRldEIctZQ SK+Iyw4ny/V8ZhPavs98OCknvn1K2nMfwUn+KMbNp0MnLDjrQczWVVQOh ChYngJwxciwtSW6mh955OknJ78p3vDIOnGloCvYjZJ9Hvv+O//XvZ38oJ 0=; X-IronPort-AV: E=Sophos;i="5.47,453,1515456000"; d="scan'208";a="359191866" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Mar 2018 03:07:19 +0000 Received: from sjc-ads-6991 (sjc-ads-6991.cisco.com [10.30.218.111]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w2B37IYN017829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Mar 2018 03:07:18 GMT Date: Sat, 10 Mar 2018 19:07:18 -0800 (PST) From: Victor Kamensky To: Stephen Smalley cc: Taras Kondratiuk , "H. Peter Anvin" , Al Viro , Arnd Bergmann , Rob Landley , Mimi Zohar , Jonathan Corbet , James McMechan , initramfs@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, xe-linux-external@cisco.com, Paul Moore , Eric Paris Subject: Re: [PATCH v3 14/15] selinux: allow setxattr on rootfs so initramfs code can set them In-Reply-To: <1519153284.14218.18.camel@tycho.nsa.gov> Message-ID: References: <1518813234-5874-1-git-send-email-takondra@cisco.com> <1518813234-5874-17-git-send-email-takondra@cisco.com> <1519153284.14218.18.camel@tycho.nsa.gov> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Auto-Response-Suppress: DR, OOF, AutoReply Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 20 Feb 2018, Stephen Smalley wrote: > On Fri, 2018-02-16 at 20:33 +0000, Taras Kondratiuk wrote: >> From: Victor Kamensky >> >> initramfs code supporting extended cpio format have ability to >> fill extended attributes from cpio archive, but if SELinux enabled >> and security server is not initialized yet, selinux callback would >> refuse setxattr made by initramfs code. >> >> Solution enable SBLABEL_MNT on rootfs even if secrurity server is >> not initialized yet. > > What if we were to instead skip the SBLABEL_MNT check in > selinux_inode_setxattr() if !ss_initialized? Not dependent on > filesystem type. Stephen, thank you for looking into this. Sorry, for dealyed reponse - I needed to find time to require context about these changes. As you suggested I've tried this and it works: >From 6bf35bd055fdb12e94f3d5188eccfdbaa30dbcf4 Mon Sep 17 00:00:00 2001 From: Victor Kamensky Date: Fri, 9 Mar 2018 23:01:20 -0800 Subject: [PATCH 1/2] selinux: allow setxattr on file systems if policy is not loaded initramfs code supporting extended cpio format have ability to fill extended attributes from cpio archive, but if SELinux enabled and security server is not initialized yet, selinux callback would refuse setxattr made by initramfs code because file system is not yet marked as one that support labeling (SBLABEL_MNT flag). Solution do not refuse setxattr even if SBLABEL_MNT is not set for file systems when policy is not loaded yet. Signed-off-by: Victor Kamensky --- security/selinux/hooks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 819fd68..31303ed 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -3120,7 +3120,7 @@ static int selinux_inode_setxattr(struct dentry *dentry, const char *name, return selinux_inode_setotherxattr(dentry, name); sbsec = inode->i_sb->s_security; - if (!(sbsec->flags & SBLABEL_MNT)) + if (!(sbsec->flags & SBLABEL_MNT) && ss_initialized) return -EOPNOTSUPP; if (!inode_owner_or_capable(inode)) -- 2.7.4 But with this change it would mean for that filesystem types, that never are supposed to get SBLABEL_MNT flag, code may go through if !ss_initialized. I have hard time evaluating impication of this, but it is not existing case or not a big deal. Generally I agree with your concern that the issue is not "rootfs" specific. Other thought that it could be solved with use of selinux_is_sblabel_mnt instead of "rootfs" specific check inside of selinux_set_mnt_opts, in addition to similar code in sb_finish_set_opts function. I.e something like this: >From a94548b5ecde43ccc9c2b02b29becc086b4343a3 Mon Sep 17 00:00:00 2001 From: Victor Kamensky Date: Fri, 9 Mar 2018 23:01:20 -0800 Subject: [PATCH 1/2] selinux: allow setxattr on rootfs so initramfs code can set them initramfs code supporting extended cpio format have ability to fill extended attributes from cpio archive, but if SELinux enabled and security server is not initialized yet, selinux callback would refuse setxattr made by initramfs code. Solution enable set SBLABEL_MNT on file systems for which we can figure out that they support securit labels even if secrurity server is not initialized yet. Signed-off-by: Victor Kamensky --- security/selinux/hooks.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 819fd68..326aca9 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -701,6 +701,18 @@ static int selinux_set_mnt_opts(struct super_block *sb, if (!ss_initialized) { if (!num_opts) { + /* + * For some of file systems we can mark them as + * supporting security labels even before policy + * loaded. It may be used by code that may want + * to do setxatts before polict load. + * + * Note after policy loaded this check and marking + * happens again. + */ + if (selinux_is_sblabel_mnt(sb)) + sbsec->flags |= SBLABEL_MNT; + /* Defer initialization until selinux_complete_init, after the initial policy is loaded and the security server is ready to handle calls. */ -- 2.7.4 Thanks, Victor >> >> Signed-off-by: Victor Kamensky >> --- >> security/selinux/hooks.c | 12 ++++++++++++ >> 1 file changed, 12 insertions(+) >> >> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c >> index 8644d864e3c1..f3fe65589f02 100644 >> --- a/security/selinux/hooks.c >> +++ b/security/selinux/hooks.c >> @@ -706,6 +706,18 @@ static int selinux_set_mnt_opts(struct >> super_block *sb, >> >> if (!ss_initialized) { >> if (!num_opts) { >> + /* >> + * Special handling for rootfs. Is genfs but >> supports >> + * setting SELinux context on in-core >> inodes. >> + * >> + * Chicken and egg problem: policy may >> reside in rootfs >> + * but for initramfs code to fill in >> attributes, it >> + * needs selinux to allow that. >> + */ >> + if (!strncmp(sb->s_type->name, "rootfs", >> + sizeof("rootfs"))) >> + sbsec->flags |= SBLABEL_MNT; >> + >> /* Defer initialization until >> selinux_complete_init, >> after the initial policy is loaded and >> the security >> server is ready to handle calls. */ >