From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E96F5C433DF for ; Fri, 17 Jul 2020 23:40:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C27CA2074B for ; Fri, 17 Jul 2020 23:40:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="Q9E6C6Tk" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726851AbgGQXkD (ORCPT ); Fri, 17 Jul 2020 19:40:03 -0400 Received: from linux.microsoft.com ([13.77.154.182]:58362 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726204AbgGQXkD (ORCPT ); Fri, 17 Jul 2020 19:40:03 -0400 Received: from sequoia (162-237-133-238.lightspeed.rcsntx.sbcglobal.net [162.237.133.238]) by linux.microsoft.com (Postfix) with ESMTPSA id B631820B4909; Fri, 17 Jul 2020 16:40:01 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com B631820B4909 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1595029202; bh=KV3ImyOek3N8TkRZ8dwks9SPetOvzDzbwBDUYTs3QEk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Q9E6C6Tks29TLfvMJfs61r72PRu5oNCR7QYnu8yFHktVoQEgSOnjISXShGu1v8cFU 4W14pUxA2qeTkFNXQKNAk1ZH7GZUMdT9gJuNBiU43IIDR8Nt0WLsBRziRW/5xlQJUx 6LGfvD9FO4gVKAGPnGZs2r6FZjKV0KIGy72a1snY= Date: Fri, 17 Jul 2020 18:39:59 -0500 From: Tyler Hicks To: Nayna , Lakshmi Ramasubramanian , Mimi Zohar Cc: Dmitry Kasatkin , James Morris , "Serge E . Hallyn" , Prakhar Srivastava , linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org Subject: Re: [PATCH v3 06/12] ima: Fail rule parsing when the KEY_CHECK hook is combined with an invalid cond Message-ID: <20200717233959.GP3673@sequoia> References: <20200709061911.954326-1-tyhicks@linux.microsoft.com> <20200709061911.954326-7-tyhicks@linux.microsoft.com> <336cc947-1f70-0286-6506-6df3d1d23a1d@linux.vnet.ibm.com> <20200717191858.GN3673@sequoia> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200717191858.GN3673@sequoia> Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org On 2020-07-17 14:19:03, Tyler Hicks wrote: > On 2020-07-17 14:56:46, Nayna wrote: > > > > On 7/9/20 2:19 AM, Tyler Hicks wrote: > > > The KEY_CHECK function only supports the uid, pcr, and keyrings > > > conditionals. Make this clear at policy load so that IMA policy authors > > > don't assume that other conditionals are supported. > > > > > > Fixes: 5808611cccb2 ("IMA: Add KEY_CHECK func to measure keys") > > > Signed-off-by: Tyler Hicks > > > Reviewed-by: Lakshmi Ramasubramanian > > > --- > > > > > > * v3 > > > - Added Lakshmi's Reviewed-by > > > - Adjust for the indentation change introduced in patch #4 > > > * v2 > > > - No change > > > > > > security/integrity/ima/ima_policy.c | 7 +++++++ > > > 1 file changed, 7 insertions(+) > > > > > > diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c > > > index 1c64bd6f1728..81da02071d41 100644 > > > --- a/security/integrity/ima/ima_policy.c > > > +++ b/security/integrity/ima/ima_policy.c > > > @@ -1023,6 +1023,13 @@ static bool ima_validate_rule(struct ima_rule_entry *entry) > > > if (entry->action & ~(MEASURE | DONT_MEASURE)) > > > return false; > > > > > > + if (entry->flags & ~(IMA_FUNC | IMA_UID | IMA_PCR | > > > + IMA_KEYRINGS)) > > > + return false; > > > + > > > + if (ima_rule_contains_lsm_cond(entry)) > > > + return false; > > > + > > > break; > > > default: > > > return false; > > > > Should there be a check for IMA_MEASURE_ASYMMETRIC_KEYS in Opt_keyrings in > > ima_parse_rule() to return immediately if not enabled ? > > I didn't notice that "keyrings=" could be disabled at build time. I > think you're right that something like what I have below would be a good idea. > > @Lakshmi, do you agree? > > diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c > index 81da02071d41..bd687560f88e 100644 > --- a/security/integrity/ima/ima_policy.c > +++ b/security/integrity/ima/ima_policy.c > @@ -1212,6 +1212,11 @@ static int ima_parse_rule(char *rule, struct ima_rule_entry *entry) > case Opt_keyrings: > ima_log_string(ab, "keyrings", args[0].from); > > + if (!IS_ENABLED(CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS)) { > + result = -EINVAL; > + break; > + } > + > keyrings_len = strlen(args[0].from) + 1; > > if ((entry->keyrings) || > Actually, this change introduces a new compiler warning in another part of the code that I need to think some more about. I'd like to leave this patch as-is for now and work on the !CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS case in a separate, later patch when I have some more time to think about it and test properly. Tyler > Tyler > > > > > Thanks & Regards, > > > >      - Nayna > >