Message ID | 20231120173318.1132868-26-roberto.sassu@huaweicloud.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2b07:b0:403:3b70:6f57 with SMTP id io7csp103371vqb; Mon, 20 Nov 2023 09:44:04 -0800 (PST) X-Google-Smtp-Source: AGHT+IHIvVojMc2fT5mtyvtEyjwD1LOm6TFEdh+z4oRdJJziUCjC9IYTJFrFaPUNvrVrHPp4TTPU X-Received: by 2002:a05:6a00:84a:b0:6bd:f760:6ab1 with SMTP id q10-20020a056a00084a00b006bdf7606ab1mr7225189pfk.14.1700502244464; Mon, 20 Nov 2023 09:44:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700502244; cv=none; d=google.com; s=arc-20160816; b=XdDYUwxvw0TrpgrGC/VBXXYDXME7U0kZNYhaGf2PjECB5T5eXu2CJm9aIEuPgq3H3N TVurmWgDDIPh97YLXSvR5N/8zr0pW6aICCw92YCtcDmQ8d/v8Y+lWa6i6yrwg0UXlucx kZuh6PSho87TE+5wq62dC4oxr7Xx21zPa2Li7cIz0/VmVWM3gdlxBwLHzhoPKJIvrjgE ymjVH9HgVYIc6TF8WKUxxr9W/vul0O2nYTUx1Nq7gmHTjF9iDwnr+5lbkCf2FbCWUrid v4olfKGFlTMKY2WRlrsu2mBAzzBxuEjngqk7fILTLYudY5VjokMQpQwUuobFGwVXQkyA TZ3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=HGtkYWky6hBXtzPtoxmEHvZb9qYcYyfEITt7wcJ6wr8=; fh=2uEWnGGvEpdqFtUqKQh3Y6uaGNgTGNOI0L2cxn3xouc=; b=WEquxrBpasdEwPchmGdOdt7XjC0sWt/v3R5nJK1UHVOCSj7NcwDxG7GY9arrdnz2L7 tMuF8Hx67xqvqN7NlCtW6C/ad0a5X+HswMXkqN0gZNi6iWjoTqXE78P/A+ZGE5a1FUsb SWMA2UEDv31tOs62hPFnpgAhzH42yD0XTRyWTD7BFjBcxaUbjbyOxXfGu7soBOuXbj54 UhSbpBwUqw06H7Qi4XDFhntt5S2Bx3KH/wg20QeVXG6nqICGUw/ZCK8qaQAUWvrMEbQb aPrMKOFqjCd71Jqzp2d1Fy8LWefOf63PIkhFbrkAdR7gQqCEAafMOplwGnnb7mA5Y6Pn yRDg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id fb34-20020a056a002da200b006b28fa70b3bsi8671461pfb.86.2023.11.20.09.44.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Nov 2023 09:44:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 0CEEE80ECF38; Mon, 20 Nov 2023 09:42:54 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234144AbjKTRmX (ORCPT <rfc822;heyuhang3455@gmail.com> + 27 others); Mon, 20 Nov 2023 12:42:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234087AbjKTRlx (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 20 Nov 2023 12:41:53 -0500 Received: from frasgout12.his.huawei.com (frasgout12.his.huawei.com [14.137.139.154]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0DE85183; Mon, 20 Nov 2023 09:41:50 -0800 (PST) Received: from mail02.huawei.com (unknown [172.18.147.229]) by frasgout12.his.huawei.com (SkyGuard) with ESMTP id 4SYvXP2hwMz9yN0H; Tue, 21 Nov 2023 01:25:09 +0800 (CST) Received: from huaweicloud.com (unknown [10.204.63.22]) by APP1 (Coremail) with SMTP id LxC2BwAXBXXxmVtlIZIKAQ--.7181S7; Mon, 20 Nov 2023 18:41:22 +0100 (CET) From: Roberto Sassu <roberto.sassu@huaweicloud.com> To: viro@zeniv.linux.org.uk, brauner@kernel.org, chuck.lever@oracle.com, jlayton@kernel.org, neilb@suse.de, kolga@netapp.com, Dai.Ngo@oracle.com, tom@talpey.com, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com, zohar@linux.ibm.com, dmitry.kasatkin@gmail.com, dhowells@redhat.com, jarkko@kernel.org, stephen.smalley.work@gmail.com, eparis@parisplace.org, casey@schaufler-ca.com, mic@digikod.net Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-security-module@vger.kernel.org, linux-integrity@vger.kernel.org, keyrings@vger.kernel.org, selinux@vger.kernel.org, Roberto Sassu <roberto.sassu@huawei.com> Subject: [PATCH v6 25/25] security: Enforce ordering of 'ima' and 'evm' LSMs Date: Mon, 20 Nov 2023 18:33:18 +0100 Message-Id: <20231120173318.1132868-26-roberto.sassu@huaweicloud.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231120173318.1132868-1-roberto.sassu@huaweicloud.com> References: <20231120173318.1132868-1-roberto.sassu@huaweicloud.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: LxC2BwAXBXXxmVtlIZIKAQ--.7181S7 X-Coremail-Antispam: 1UD129KBjvJXoW7tw1xtry5KF18uFW7GrW8Xrb_yoW8Aw4xpa naqFW3Kr48JF1Igwn3Ja17GF1a9rWkCF13JrnxJw1DZa9Fqr1vyr43JrySvFyDXry8Aa4S qr429w1rKws0vaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPIb4IE77IF4wAFF20E14v26rWj6s0DM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28IrcIa0xkI8VA2jI8067AKxVWUAV Cq3wA2048vs2IY020Ec7CjxVAFwI0_Xr0E3s1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0 rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW7JVWDJwA2z4x0Y4vE2Ix0cI8IcVCY1x0267 AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIE14v26F4j6r4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAF wI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2 WlYx0E2Ix0cI8IcVAFwI0_JF0_Jw1lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkE bVWUJVW8JwACjcxG0xvY0x0EwIxGrwACI402YVCY1x02628vn2kIc2xKxwCY1x0262kKe7 AKxVW8ZVWrXwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02 F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_GFv_Wr ylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW7JVWDJwCI42IY6xIIjxv20xvEc7Cj xVAFwI0_GcCE3s1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26F 4j6r4UJwCI42IY6I8E87Iv6xkF7I0E14v26rxl6s0DYxBIdaVFxhVjvjDU0xZFpf9x07jx WrAUUUUU= X-CM-SenderInfo: purev21wro2thvvxqx5xdzvxpfor3voofrz/1tbiAgAHBF1jj5KqdgABs- X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 20 Nov 2023 09:42:54 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783105841598447419 X-GMAIL-MSGID: 1783105841598447419 |
Series |
security: Move IMA and EVM to the LSM infrastructure
|
|
Commit Message
Roberto Sassu
Nov. 20, 2023, 5:33 p.m. UTC
From: Roberto Sassu <roberto.sassu@huawei.com> The ordering of LSM_ORDER_LAST LSMs depends on how they are placed in the .lsm_info.init section of the kernel image. Without making any assumption on the LSM ordering based on how they are compiled, enforce that ordering at LSM infrastructure level. Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> --- security/security.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
Comments
On 11/20/2023 9:33 AM, Roberto Sassu wrote: > From: Roberto Sassu <roberto.sassu@huawei.com> > > The ordering of LSM_ORDER_LAST LSMs depends on how they are placed in the > .lsm_info.init section of the kernel image. > > Without making any assumption on the LSM ordering based on how they are > compiled, enforce that ordering at LSM infrastructure level. > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > --- > security/security.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/security/security.c b/security/security.c > index 351a124b771c..b98db79ca500 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -263,6 +263,18 @@ static void __init initialize_lsm(struct lsm_info *lsm) > } > } > > +/* Find an LSM with a given name. */ > +static struct lsm_info __init *find_lsm(const char *name) > +{ > + struct lsm_info *lsm; > + > + for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) > + if (!strcmp(lsm->name, name)) > + return lsm; > + > + return NULL; > +} > + > /* > * Current index to use while initializing the lsm id list. > */ > @@ -333,10 +345,23 @@ static void __init ordered_lsm_parse(const char *order, const char *origin) > > /* LSM_ORDER_LAST is always last. */ > for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) { > + /* Do it later, to enforce the expected ordering. */ > + if (!strcmp(lsm->name, "ima") || !strcmp(lsm->name, "evm")) > + continue; > + Hard coding the ordering of LSMs is incredibly ugly and unlikely to scale. Not to mention perplexing the next time someone creates an LSM that "has to be last". Why isn't LSM_ORDER_LAST sufficient? If it really isn't, how about adding and using LSM_ORDER_LAST_I_REALLY_MEAN_IT* ? Alternatively, a declaration of ordering requirements with regard to other LSMs in lsm_info. You probably don't care where ima is relative to Yama, but you need to be after SELinux and before evm. lsm_info could have must_precede and must_follow lists. Maybe a must_not_combine list, too, although I'm hoping to make that unnecessary. And you should be using LSM_ID values instead of LSM names. --- * Naming subject to Paul's sensibilities, of course. > if (lsm->order == LSM_ORDER_LAST) > append_ordered_lsm(lsm, " last"); > } > > + /* Ensure that the 'ima' and 'evm' LSMs are last and in this order. */ > + lsm = find_lsm("ima"); > + if (lsm) > + append_ordered_lsm(lsm, " last"); > + > + lsm = find_lsm("evm"); > + if (lsm) > + append_ordered_lsm(lsm, " last"); > + > /* Disable all LSMs not in the ordered list. */ > for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) { > if (exists_ordered_lsm(lsm))
On Mon, 2023-11-20 at 16:50 -0800, Casey Schaufler wrote: > On 11/20/2023 9:33 AM, Roberto Sassu wrote: > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > The ordering of LSM_ORDER_LAST LSMs depends on how they are placed in the > > .lsm_info.init section of the kernel image. > > > > Without making any assumption on the LSM ordering based on how they are > > compiled, enforce that ordering at LSM infrastructure level. > > > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > > --- > > security/security.c | 25 +++++++++++++++++++++++++ > > 1 file changed, 25 insertions(+) > > > > diff --git a/security/security.c b/security/security.c > > index 351a124b771c..b98db79ca500 100644 > > --- a/security/security.c > > +++ b/security/security.c > > @@ -263,6 +263,18 @@ static void __init initialize_lsm(struct lsm_info *lsm) > > } > > } > > > > +/* Find an LSM with a given name. */ > > +static struct lsm_info __init *find_lsm(const char *name) > > +{ > > + struct lsm_info *lsm; > > + > > + for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) > > + if (!strcmp(lsm->name, name)) > > + return lsm; > > + > > + return NULL; > > +} > > + > > /* > > * Current index to use while initializing the lsm id list. > > */ > > @@ -333,10 +345,23 @@ static void __init ordered_lsm_parse(const char *order, const char *origin) > > > > /* LSM_ORDER_LAST is always last. */ > > for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) { > > + /* Do it later, to enforce the expected ordering. */ > > + if (!strcmp(lsm->name, "ima") || !strcmp(lsm->name, "evm")) > > + continue; > > + > > Hard coding the ordering of LSMs is incredibly ugly and unlikely to scale. > Not to mention perplexing the next time someone creates an LSM that "has to be last". Uhm, yes, not the best solution. > Why isn't LSM_ORDER_LAST sufficient? If it really isn't, how about adding > and using LSM_ORDER_LAST_I_REALLY_MEAN_IT* ? I don't know if the order at run-time reflects the order in the Makefile (EVM is compiled after IMA). If it does, there is no need for this patch. > Alternatively, a declaration of ordering requirements with regard to other > LSMs in lsm_info. You probably don't care where ima is relative to Yama, > but you need to be after SELinux and before evm. lsm_info could have > must_precede and must_follow lists. Maybe a must_not_combine list, too, > although I'm hoping to make that unnecessary. Uhm, I agree. Will think about how to make it more straightforward. > And you should be using LSM_ID values instead of LSM names. Ok. Thanks Roberto > --- > * Naming subject to Paul's sensibilities, of course. > > > if (lsm->order == LSM_ORDER_LAST) > > append_ordered_lsm(lsm, " last"); > > } > > > > + /* Ensure that the 'ima' and 'evm' LSMs are last and in this order. */ > > + lsm = find_lsm("ima"); > > + if (lsm) > > + append_ordered_lsm(lsm, " last"); > > + > > + lsm = find_lsm("evm"); > > + if (lsm) > > + append_ordered_lsm(lsm, " last"); > > + > > /* Disable all LSMs not in the ordered list. */ > > for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) { > > if (exists_ordered_lsm(lsm))
diff --git a/security/security.c b/security/security.c index 351a124b771c..b98db79ca500 100644 --- a/security/security.c +++ b/security/security.c @@ -263,6 +263,18 @@ static void __init initialize_lsm(struct lsm_info *lsm) } } +/* Find an LSM with a given name. */ +static struct lsm_info __init *find_lsm(const char *name) +{ + struct lsm_info *lsm; + + for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) + if (!strcmp(lsm->name, name)) + return lsm; + + return NULL; +} + /* * Current index to use while initializing the lsm id list. */ @@ -333,10 +345,23 @@ static void __init ordered_lsm_parse(const char *order, const char *origin) /* LSM_ORDER_LAST is always last. */ for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) { + /* Do it later, to enforce the expected ordering. */ + if (!strcmp(lsm->name, "ima") || !strcmp(lsm->name, "evm")) + continue; + if (lsm->order == LSM_ORDER_LAST) append_ordered_lsm(lsm, " last"); } + /* Ensure that the 'ima' and 'evm' LSMs are last and in this order. */ + lsm = find_lsm("ima"); + if (lsm) + append_ordered_lsm(lsm, " last"); + + lsm = find_lsm("evm"); + if (lsm) + append_ordered_lsm(lsm, " last"); + /* Disable all LSMs not in the ordered list. */ for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) { if (exists_ordered_lsm(lsm))