linux-kernel - Re: [PATCH] security: Fix IMA Kconfig for dependencies on ARM64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1520461156.10396.654.camel@linux.vnet.ibm.com>
Date:   Wed, 07 Mar 2018 17:19:16 -0500
From:   Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:     James Bottomley <James.Bottomley@...senPartnership.com>,
        Jason Gunthorpe <jgg@...pe.ca>,
        Jiandi An <anjiandi@...eaurora.org>
Cc:     dmitry.kasatkin@...il.com, jmorris@...ei.org, serge@...lyn.com,
        linux-integrity@...r.kernel.org,
        linux-ima-devel@...ts.sourceforge.net,
        linux-ima-user@...ts.sourceforge.net,
        linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] security: Fix IMA Kconfig for dependencies on ARM64

On Wed, 2018-03-07 at 11:41 -0800, James Bottomley wrote:
> On Wed, 2018-03-07 at 14:21 -0500, Mimi Zohar wrote:
> > On Wed, 2018-03-07 at 11:08 -0800, James Bottomley wrote:
> > > 
> > > On Wed, 2018-03-07 at 13:55 -0500, Mimi Zohar wrote:
> > > > 
> > > > On Wed, 2018-03-07 at 11:51 -0700, Jason Gunthorpe wrote:
> > > > > 
> > > > > 
> > > > > On Tue, Mar 06, 2018 at 11:26:26PM -0600, Jiandi An wrote:
> > > > > > 
> > > > > > 
> > > > > > TPM_CRB driver is the TPM support for ARM64.  If it
> > > > > > is built as module, TPM chip is registered after IMA
> > > > > > init.  tpm_pcr_read() in IMA driver would fail and
> > > > > > display the following message even though eventually
> > > > > > there is TPM chip on the system:
> > > > > > 
> > > > > > ima: No TPM chip found, activating TPM-bypass! (rc=-19)
> > > > > > 
> > > > > > Fix IMA Kconfig to select TPM_CRB so TPM_CRB driver is
> > > > > > built in kernel and initializes before IMA driver.
> > > > > > 
> > > > > > Signed-off-by: Jiandi An <anjiandi@...eaurora.org>
> > > > > >  security/integrity/ima/Kconfig | 1 +
> > > > > >  1 file changed, 1 insertion(+)
> > > > > > 
> > > > > > diff --git a/security/integrity/ima/Kconfig
> > > > > > b/security/integrity/ima/Kconfig
> > > > > > index 35ef693..6a8f677 100644
> > > > > > +++ b/security/integrity/ima/Kconfig
> > > > > > @@ -10,6 +10,7 @@ config IMA
> > > > > >  	select CRYPTO_HASH_INFO
> > > > > >  	select TCG_TPM if HAS_IOMEM && !UML
> > > > > >  	select TCG_TIS if TCG_TPM && X86
> > > 
> > > Well, this explains why IMA doesn't work on one of my X86 systems:
> > > it's got a non i2c infineon TPM.
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > +	select TCG_CRB if TCG_TPM && ACPI
> > > > > >  	select TCG_IBMVTPM if TCG_TPM && PPC_PSERIES
> > > > > >  	help
> > > > > >  	  The Trusted Computing Group(TCG) runtime Integrity
> > > > > 
> > > > > This seems really weird, why are any specific TPM drivers
> > > > > linked to IMA config, we have lots of drivers..
> > > > > 
> > > > > I don't think I've ever seen this pattern in Kconfig before?
> > > > 
> > > > As you've seen by the current discussions, the TPM driver needs
> > > > to be initialized prior to IMA.  Otherwise IMA goes into TPM-
> > > > bypass mode.  That implies that the TPM must be builtin to the
> > > > kernel, and not as a kernel module.
> > > 
> > > Actually, that's not necessarily true:  If we don't begin appraisal
> > > until after the initrd phase, then the initrd can load TPM modules
> > > before IMA starts.
> > > 
> > > This would involve a bit of code rejigging to not require a TPM
> > > until IMA wants to write its first measurement, but it looks doable
> > > and would get us out of having to second guess TPM selections.
> > 
> > The question is about measurement, not appraisal.  Although the
> > initramfs might be measured, the initramfs can access files on the
> > real root filesystem.  Those files need to be measured, before they
> > are used/accessed.
> 
> Isn't it a question of threat model?  Because the initrd is measured,
> you know it's the one you specified and you should know its security
> properties, so measurement doesn't really need to begin until the root
> pivots.

Perhaps in the case where the initramfs is signed and the signature is
verified, I would agree that I know the security properties of the
initramfs.  That still doesn't negate the fact that the initramfs
could access files on real root, without first measuring them.

> At that point you pick up the boot aggregate so the log now is
> tied to the initrd measurement.  Conversely, I can't really see a
> threat model where you could trick a correctly measured initrd into
> subverting IMA, especially because listening network daemons aren't
> usually active at this stage.

Linux based boot loaders can be configured to download remote kernel
images and initramfs files - network boot.

> I'm not saying there isn't a use case for wanting your TPM built in,
> I'm just saying I don't think it needs to be required for everyone who
> uses IMA.

If the TPM module is not builtin, there are no guarantees when it was
loaded.  There could be a disconnect between the IMA measurement list
and the TPM PCRs.

If someone has a special use case, then I agree with you, that we
could theoretically support it, but I don't think we want to confuse
distros or anyone else.  The TPM should be builtin, so that IMA
measurements can begin before accessing real root.

Mimi