Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <1593785732.23056.16.camel@linux.ibm.com>
Subject: Re: [PATCH v2 09/11] ima: Move validation of the keyrings
 conditional into ima_validate_rule()
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     Tyler Hicks <tyhicks@linux.microsoft.com>
Cc:     Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
        James Morris <jmorris@namei.org>,
        "Serge E . Hallyn" <serge@hallyn.com>,
        Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
        Prakhar Srivastava <prsriva02@gmail.com>,
        linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org,
        linux-security-module@vger.kernel.org
Date:   Fri, 03 Jul 2020 10:15:32 -0400
In-Reply-To: <20200702221656.GH4694@sequoia>
References: <20200626223900.253615-1-tyhicks@linux.microsoft.com>
         <20200626223900.253615-10-tyhicks@linux.microsoft.com>
         <1593558449.5057.12.camel@linux.ibm.com> <20200702221656.GH4694@sequoia>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, 2020-07-02 at 17:16 -0500, Tyler Hicks wrote:
> On 2020-06-30 19:07:29, Mimi Zohar wrote:
> > On Fri, 2020-06-26 at 17:38 -0500, Tyler Hicks wrote:
> > > Use ima_validate_rule() to ensure that the combination of a hook
> > > function and the keyrings conditional is valid and that the keyrings
> > > conditional is not specified without an explicit KEY_CHECK func
> > > conditional. This is a code cleanup and has no user-facing change.
> > > 
> > > Signed-off-by: Tyler Hicks <tyhicks@linux.microsoft.com>
> > > ---
> > > 
> > > * v2
> > >   - Allowed IMA_DIGSIG_REQUIRED, IMA_PERMIT_DIRECTIO,
> > >     IMA_MODSIG_ALLOWED, and IMA_CHECK_BLACKLIST conditionals to be
> > >     present in the rule entry flags for non-buffer hook functions.
> > > 
> > >  security/integrity/ima/ima_policy.c | 13 +++++++++++--
> > >  1 file changed, 11 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
> > > index 8cdca2399d59..43d49ad958fb 100644
> > > --- a/security/integrity/ima/ima_policy.c
> > > +++ b/security/integrity/ima/ima_policy.c
> > > @@ -1000,6 +1000,15 @@ static bool ima_validate_rule(struct ima_rule_entry *entry)
> > >  		case KEXEC_KERNEL_CHECK:
> > >  		case KEXEC_INITRAMFS_CHECK:
> > >  		case POLICY_CHECK:
> > > +			if (entry->flags & ~(IMA_FUNC | IMA_MASK | IMA_FSMAGIC |
> > > +					     IMA_UID | IMA_FOWNER | IMA_FSUUID |
> > > +					     IMA_INMASK | IMA_EUID | IMA_PCR |
> > > +					     IMA_FSNAME | IMA_DIGSIG_REQUIRED |
> > > +					     IMA_PERMIT_DIRECTIO |
> > > +					     IMA_MODSIG_ALLOWED |
> > > +					     IMA_CHECK_BLACKLIST))
> > 
> > Other than KEYRINGS, this patch should continue to behave the same.
> >  However, this list gives the impressions that all of these flags are
> > permitted on all of the above flags, which isn't true.
> > 
> > For example, both IMA_MODSIG_ALLOWED & IMA_CHECK_BLACKLIST are limited
> > to appended signatures, meaning KERNEL_CHECK and KEXEC_KERNEL_CHECK.
> 
> Just to clarify, are both IMA_MODSIG_ALLOWED and IMA_CHECK_BLACKLIST
> limited to KEXEC_KERNEL_CHECK, KEXEC_INITRAMFS_CHECK, and MODULE_CHECK?
> That's what ima_hook_supports_modsig() suggests.

Theoretically that is true, but I have no idea how you would append a
signature to the kexec boot command line.  The only users of appended
signatures are currently kernel modules and the kexec'ed kernel image.

> 
> >  Both should only be allowed on APPRAISE action rules.
> 
> For completeness, it looks like DONT_APPRAISE should not be allowed.

Good point.  

> 
> > IMA_PCR should be limited to MEASURE action rules.
> 
> It looks like DONT_MEASURE should not be allowed.

The TPM PCR isn't a file attribute.

> 
> > IMA_DIGSIG_REQUIRED should be limited to APPRAISE action rules.
> 
> It looks like DONT_APPRAISE should not be allowed.

Right, in all of these cases the DONT_XXXX isn't applicable.

Mimi