| Message ID | 1520400386-17674-1-git-send-email-anjiandi@codeaurora.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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@codeaurora.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 > + 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? Jason
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@codeaurora.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 > > + 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. Mimi
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@codeaurora.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. James
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@codeaurora.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. Mimi
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@codeaurora.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. 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. 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. James
On 03/07/2018 01:41 PM, 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@codeaurora.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. 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. > > 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. > > James > ima_init() first calls tpm_pcr_read() which tries to use underlying registered TPM chip driver and send read PCR TPM command to the TPM chip. If IMA driver is enabled and ima_init() happens, we see this. In security/integrity/ima/ima_main.c, init_ima() is in late_initcall. And it calls ima_init(). late_initcall(init_ima); /* Start IMA after the TPM is available */ So as long as init_ima() is called, need to at least enable the TPM driver for the platform right? I'm just following current IMA Kconfig where it's selecting different underlying TPM chip drivers for various platforms respectively when CONFIG_IMA is set to Y because IMA driver init calls tpm_pcr_read() which needs to use TPM.
On Wed, 2018-03-07 at 15:12 -0600, Jiandi An wrote: > > On 03/07/2018 01:41 PM, 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@codeaurora.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. 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. > > > > 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. > > > > James > > > > ima_init() first calls tpm_pcr_read() which tries to use underlying > registered TPM chip driver and send read PCR TPM command to the TPM > chip. If IMA driver is enabled and ima_init() happens, we see this. > > In security/integrity/ima/ima_main.c, init_ima() is in late_initcall. > And it calls ima_init(). > > late_initcall(init_ima); /* Start IMA after the TPM is available */ > > So as long as init_ima() is called, need to at least enable the > TPM driver for the platform right? Well, that's not really relevant: I said "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" James > I'm just following current IMA Kconfig where it's selecting different > underlying TPM chip drivers for various platforms respectively when > CONFIG_IMA is set to Y because IMA driver init calls tpm_pcr_read() > which needs to use TPM. >
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@codeaurora.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
On 03/07/2018 04:19 PM, Mimi Zohar wrote: > 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@codeaurora.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 > So from the discussion, I hear James suggests to overhaul the current IMA driver to not do measurement (calling tpm_pcr_read(), etc) until after initrd phase so TPM drivers can be built as modules. I hear Mimi insists TPM drivers should be built-in when IMA driver is enabled and set to Y in Kconfig. Do we have a consensus on which way we should go? I'm no expert on IMA and its driver. James, will you be kind enough to look into overhauling the IMA driver to not measure until after initrd phase if that's the consensus on resolving this? Thanks -Jiandi
On Thu, 2018-03-08 at 12:42 -0600, Jiandi An wrote: > So from the discussion, I hear James suggests to overhaul the current > IMA driver to not do measurement (calling tpm_pcr_read(), etc) until > after initrd phase so TPM drivers can be built as modules. > > I hear Mimi insists TPM drivers should be built-in when IMA driver is > enabled and set to Y in Kconfig. > > Do we have a consensus on which way we should go? > > I'm no expert on IMA and its driver. James, will you be kind enough > to look into overhauling the IMA driver to not measure until after > initrd phase if that's the consensus on resolving this? IMA selecting the TPM forces the TPM to be builtin. There's nothing keeping you from directly configuring the TPM driver as builtin. For remote attestation to validate the IMA measurement list against the PCRs, the existing "ima_tcb" and "ima_policy=tcb" builtin policies require the TPM to be builtin. Not building the TPM into the kernel will also affect EVM. I don't have a problem accepting your patch now; and if/when there is a real use case for building the TPM driver as a kernel module for use with IMA-measurement, accepting those changes then. Mimi
On Thu, 2018-03-08 at 12:42 -0600, Jiandi An wrote: [...] > I'm no expert on IMA and its driver. James, will you be kind enough > to look into overhauling the IMA driver to not measure until after > initrd phase if that's the consensus on resolving this? I'll add it to my todo list. Since my TPM 2.0 test environment is a VM with a tpm that has a network connection to an emulator on my host, it's impossible to set it up so that it's built in (because you need the network config before you init the TPM) so I might accelerate if I suddenly need to debug IMA issues in this configuration. James
On Tue, 2018-03-06 at 23:26 -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@codeaurora.org> Thanks, this patch has been applied. Mimi > --- > 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 > --- a/security/integrity/ima/Kconfig > +++ 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 > + select TCG_CRB if TCG_TPM && ACPI > select TCG_IBMVTPM if TCG_TPM && PPC_PSERIES > help > The Trusted Computing Group(TCG) runtime Integrity
On Fri, 2018-03-09 at 09:11 -0800, James Bottomley wrote: > On Thu, 2018-03-08 at 12:42 -0600, Jiandi An wrote: > [...] > > I'm no expert on IMA and its driver. James, will you be kind enough > > to look into overhauling the IMA driver to not measure until after > > initrd phase if that's the consensus on resolving this? > > I'll add it to my todo list. > > Since my TPM 2.0 test environment is a VM with a tpm that has a network > connection to an emulator on my host, it's impossible to set it up so > that it's built in (because you need the network config before you init > the TPM) so I might accelerate if I suddenly need to debug IMA issues > in this configuration. There are a number of different issues being discussed. - When IMA is enabled, unlike some other TPM device drivers, the TPM 2.0 is not forced to be builtin. This is addressed by Jiandi's patch. - Jason's comment questioning having Kconfig force the TPM to be builtin. Using Kconfig to force the TPM to be builtin is not required, but helpful. Users interested in IMA-measurement could configure the TPM as builtin themselves. Without the TPM builtin, IMA goes into TPM- bypass mode. Extending a TPM with IMA measurements, which was not builtin, but loaded at some unspecified point in time, changes the existing meaning of the IMA-measurement list. - This use case, when the TPM is not builtin and unavailable before IMA is initialized. I would classify this use case as an IMA testing/debugging environment, when it cannot, for whatever reason, be builtin the kernel or initialized before IMA. From Dave Safford: For the TCG chain of trust to have any meaning, all files have to be measured and extended into the TPM before they are accessed. If the TPM driver is loaded after any unmeasured file, the chain is broken, and IMA is useless for any use case or any threat model. While the initramfs may be measured by the bootloader, there are two problems: 1. IMA has no way of knowing if the kernel or initramfs has accessed any unmeasured files before TPM driver loading and IMA initialization. 2. Even if we can somehow guarantee that nothing outside the initramfs has been accessed prior to IMA initialization, it is difficult if not impossible for the attestation server to know what a good initramfs measurement should be, as the initramfs is built on the suspect device in the first place. We can sort of trust the initramfs measurement in the reference manifest, but after that, the attestation server has no way to trust a reported initramfs measurement. Mimi
On Mon, Mar 12, 2018 at 05:53:18PM -0400, Mimi Zohar wrote: > Using Kconfig to force the TPM to be builtin is not required, but > helpful. Users interested in IMA-measurement could configure the TPM > as builtin themselves. Without the TPM builtin, IMA goes into TPM- > bypass mode. This issues, broadly speaking, we have lots of TPM drivers, selecting only some to actually support IMA shows we have some kind of problem here. eg a distro on ARM should not have some TPM hardware work with IMA and some fail just because of this kconfig. IMHO if we want to do this, then IMA should completely disable modular TPM drivers across the board. Or, IMA folks need to figure out how to safely load TPM modules under their constraints. But this current kconfig approach is pretty weird.. Jason
On Mon, 2018-03-12 at 17:53 -0400, Mimi Zohar wrote: > On Fri, 2018-03-09 at 09:11 -0800, James Bottomley wrote: > > > > On Thu, 2018-03-08 at 12:42 -0600, Jiandi An wrote: > > [...] > > > > > > I'm no expert on IMA and its driver. James, will you be kind > > > enough to look into overhauling the IMA driver to not measure > > > until after initrd phase if that's the consensus on resolving > > > this? > > > > I'll add it to my todo list. > > > > Since my TPM 2.0 test environment is a VM with a tpm that has a > > network connection to an emulator on my host, it's impossible to > > set it up so that it's built in (because you need the network > > config before you init the TPM) so I might accelerate if I suddenly > > need to debug IMA issues in this configuration. > > There are a number of different issues being discussed. > > - When IMA is enabled, unlike some other TPM device drivers, the TPM > 2.0 is not forced to be builtin. > > This is addressed by Jiandi's patch. > > - Jason's comment questioning having Kconfig force the TPM to be > builtin. > > Using Kconfig to force the TPM to be builtin is not required, but > helpful. Users interested in IMA-measurement could configure the TPM > as builtin themselves. Without the TPM builtin, IMA goes into TPM- > bypass mode. > > Extending a TPM with IMA measurements, which was not builtin, but > loaded at some unspecified point in time, changes the existing > meaning of the IMA-measurement list. > > - This use case, when the TPM is not builtin and unavailable before > IMA is initialized. > > I would classify this use case as an IMA testing/debugging > environment, when it cannot, for whatever reason, be builtin the > kernel or initialized before IMA. > > From Dave Safford: > For the TCG chain of trust to have any meaning, all files have to > be measured and extended into the TPM before they are accessed. > If > the TPM driver is loaded after any unmeasured file, the chain is > broken, and IMA is useless for any use case or any threat model. I don't think this is quite the correct characterisation. In principle the kernel could also touch the files before IMA is loaded. However, we know from the way the kernel operates that it doesn't. We basically trust that the kernel measurement tells us this. The same thing can be made to apply to the initrd. The key question is not whether the component could theoretically access the files but whether it actually does so. > While the initramfs may be measured by the bootloader, there are > two problems: > 1. IMA has no way of knowing if the kernel or initramfs has > accessed any unmeasured files before TPM driver loading and IMA > initialization. > 2. Even if we can somehow guarantee that nothing outside the > initramfs has been accessed prior to IMA initialization, it is > difficult if not impossible for the attestation server to know > what > a good initramfs measurement should be, as the initramfs is built > on the suspect device in the first place. We can sort of trust > the > initramfs measurement in the reference manifest, If I don't trust the initrd then I also can't really make much of IMA measurements because the chain of custody is broken. The assertion that the initrd has to be part of the chain of custody is really a statement of the current position. Therefore if the initrd is part of that chain, then we don't have to start IMA at kernel init, we can start it at initrd pivot_root. (or to put it in simple terms: IMA measurements of the root filesystem, even if they begin at kernel init, cannot make up for a malicious initrd because the damage will already have been done before we pivot to the real root). In theory the build device shouldn't be suspect because it was measured and appraised before I built my initrd on it. > but after that, > the attestation server has no way to trust a reported initramfs > measurement. This is more a reflection of problems in the current attestation architecture and measurement gaps we have. We certainly know what the initrd measurement should be when we create it, so the expected value can be communicated to the attestation server when the initrd is built. Conversely, if the attestation server doesn't measure the initrd this is a current gap in the attestation of the custody chain because any problem with the initrd would go undetected. James
On Mon, 2018-03-12 at 15:59 -0600, Jason Gunthorpe wrote: > On Mon, Mar 12, 2018 at 05:53:18PM -0400, Mimi Zohar wrote: > > > Using Kconfig to force the TPM to be builtin is not required, but > > helpful. Users interested in IMA-measurement could configure the TPM > > as builtin themselves. Without the TPM builtin, IMA goes into TPM- > > bypass mode. > > This issues, broadly speaking, we have lots of TPM drivers, selecting > only some to actually support IMA shows we have some kind of problem > here. True, IMA is not selecting the older TPM vendor specific modules, but only the newer TPM_TIS and now TPM_CRB modules. That doesn't imply that IMA only supports some TPMs. It means that by default, these TPMs are builtin. Anyone building a kernel, can select the vendor specific TPM to be builtin. Mimi
On Mon, Mar 12, 2018 at 06:58:45PM -0400, Mimi Zohar wrote: > On Mon, 2018-03-12 at 15:59 -0600, Jason Gunthorpe wrote: > > On Mon, Mar 12, 2018 at 05:53:18PM -0400, Mimi Zohar wrote: > > > > > Using Kconfig to force the TPM to be builtin is not required, but > > > helpful. Users interested in IMA-measurement could configure the TPM > > > as builtin themselves. Without the TPM builtin, IMA goes into TPM- > > > bypass mode. > > > > This issues, broadly speaking, we have lots of TPM drivers, selecting > > only some to actually support IMA shows we have some kind of problem > > here. > > True, IMA is not selecting the older TPM vendor specific modules, but > only the newer TPM_TIS and now TPM_CRB modules. That doesn't imply > that IMA only supports some TPMs. It means that by default, these > TPMs are builtin. Anyone building a kernel, can select the vendor > specific TPM to be builtin. That doesn't help distros, which is the main point of the complaint with this scheme :) Jaason
On Mon, 2018-03-12 at 17:05 -0600, Jason Gunthorpe wrote: > On Mon, Mar 12, 2018 at 06:58:45PM -0400, Mimi Zohar wrote: > > On Mon, 2018-03-12 at 15:59 -0600, Jason Gunthorpe wrote: > > > On Mon, Mar 12, 2018 at 05:53:18PM -0400, Mimi Zohar wrote: > > > > > > > Using Kconfig to force the TPM to be builtin is not required, but > > > > helpful. Users interested in IMA-measurement could configure the TPM > > > > as builtin themselves. Without the TPM builtin, IMA goes into TPM- > > > > bypass mode. > > > > > > This issues, broadly speaking, we have lots of TPM drivers, selecting > > > only some to actually support IMA shows we have some kind of problem > > > here. > > > > True, IMA is not selecting the older TPM vendor specific modules, but > > only the newer TPM_TIS and now TPM_CRB modules. That doesn't imply > > that IMA only supports some TPMs. It means that by default, these > > TPMs are builtin. Anyone building a kernel, can select the vendor > > specific TPM to be builtin. > > That doesn't help distros, which is the main point of the complaint > with this scheme :) Years ago because of faulty TPM drivers, IMA was disabled in one of the main distro's. Deciding which vendor specific TPMs should be builtin, is a discussion between the distro's and TPM vendors. Mimi
On Mon, 2018-03-12 at 15:30 -0700, James Bottomley wrote: > On Mon, 2018-03-12 at 17:53 -0400, Mimi Zohar wrote: [...] > > - This use case, when the TPM is not builtin and unavailable before > > IMA is initialized. > > > > I would classify this use case as an IMA testing/debugging > > environment, when it cannot, for whatever reason, be builtin the > > kernel or initialized before IMA. > > > > From Dave Safford: > > For the TCG chain of trust to have any meaning, all files have to > > be measured and extended into the TPM before they are accessed. > > If > > the TPM driver is loaded after any unmeasured file, the chain is > > broken, and IMA is useless for any use case or any threat model. > > I don't think this is quite the correct characterisation. In principle > the kernel could also touch the files before IMA is loaded. However, > we know from the way the kernel operates that it doesn't. We basically > trust that the kernel measurement tells us this. The same thing can be > made to apply to the initrd. With the builtin "tcb" policy, IMA-measurement is enabled from the very beginning. Afterwards, the system can transition to a custom policy based on finer grain LSM labels, which aren't available on boot. > The key question is not whether the component could theoretically > access the files but whether it actually does so. As much as you might think you know what is included in the initramfs, IMA-measurement is your safety net, including everything accessed in the TCB. Mimi
On Mon, 2018-03-12 at 19:30 -0400, Mimi Zohar wrote: > On Mon, 2018-03-12 at 15:30 -0700, James Bottomley wrote: > > > > On Mon, 2018-03-12 at 17:53 -0400, Mimi Zohar wrote: > [...] > > > > > > > > - This use case, when the TPM is not builtin and unavailable > > > before > > > IMA is initialized. > > > > > > I would classify this use case as an IMA testing/debugging > > > environment, when it cannot, for whatever reason, be builtin the > > > kernel or initialized before IMA. > > > > > > From Dave Safford: > > > For the TCG chain of trust to have any meaning, all files > > > have to > > > be measured and extended into the TPM before they are > > > accessed. > > > If > > > the TPM driver is loaded after any unmeasured file, the chain > > > is > > > broken, and IMA is useless for any use case or any threat > > > model. > > > > I don't think this is quite the correct characterisation. In > > principle the kernel could also touch the files before IMA is > > loaded. However, we know from the way the kernel operates that it > > doesn't. We basically trust that the kernel measurement tells us > > this. The same thing can be made to apply to the initrd. > > With the builtin "tcb" policy, IMA-measurement is enabled from the > very beginning. Afterwards, the system can transition to a custom > policy based on finer grain LSM labels, which aren't available on > boot. > > > > > The key question is not whether the component could theoretically > > access the files but whether it actually does so. > > As much as you might think you know what is included in the > initramfs, IMA-measurement is your safety net, including everything > accessed in the TCB. The initrd *is* part of the Trusted Computing Base because it's part of the boot custody chain. That's really my point. If I don't know what's in my initrd, I've broken the chain there and IMA can't fix it. James
> -----Original Message----- > From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com] > Sent: Monday, March 12, 2018 8:07 PM > To: Mimi Zohar <zohar@linux.vnet.ibm.com>; Jiandi An > <anjiandi@codeaurora.org>; Jason Gunthorpe <jgg@ziepe.ca> > Cc: dmitry.kasatkin@gmail.com; jmorris@namei.org; serge@hallyn.com; > linux-integrity@vger.kernel.org; linux-ima-devel@lists.sourceforge.net; > linux-ima-user@lists.sourceforge.net; linux-security- > module@vger.kernel.org; linux-kernel@vger.kernel.org; Safford, David (GE > Global Research, US) <david.safford@ge.com> > Subject: EXT: Re: [PATCH] security: Fix IMA Kconfig for dependencies on > ARM64 > > On Mon, 2018-03-12 at 19:30 -0400, Mimi Zohar wrote: > > On Mon, 2018-03-12 at 15:30 -0700, James Bottomley wrote: > > > > > > On Mon, 2018-03-12 at 17:53 -0400, Mimi Zohar wrote: > > [...] > > > > > > > > > > > - This use case, when the TPM is not builtin and unavailable > > > > before IMA is initialized. > > > > > > > > I would classify this use case as an IMA testing/debugging > > > > environment, when it cannot, for whatever reason, be builtin the > > > > kernel or initialized before IMA. > > > > > > > > From Dave Safford: > > > > For the TCG chain of trust to have any meaning, all files have > > > > to > > > > be measured and extended into the TPM before they are > > > > accessed. > > > > If > > > > the TPM driver is loaded after any unmeasured file, the chain > > > > is > > > > broken, and IMA is useless for any use case or any threat > > > > model. > > > > > > I don't think this is quite the correct characterisation. In > > > principle the kernel could also touch the files before IMA is > > > loaded. However, we know from the way the kernel operates that it > > > doesn't. We basically trust that the kernel measurement tells us > > > this. The same thing can be made to apply to the initrd. > > > > With the builtin "tcb" policy, IMA-measurement is enabled from the > > very beginning. Afterwards, the system can transition to a custom > > policy based on finer grain LSM labels, which aren't available on > > boot. > > > > > > > > The key question is not whether the component could theoretically > > > access the files but whether it actually does so. > > > > As much as you might think you know what is included in the initramfs, > > IMA-measurement is your safety net, including everything accessed in > > the TCB. > > The initrd *is* part of the Trusted Computing Base because it's part of the > boot custody chain. That's really my point. If I don't know what's in my initrd, > I've broken the chain there and IMA can't fix it. > > James That's exactly the point - how do you know what's in your initrd? The initrd is normally built on the possibly compromised system in question. It's not signed as a whole by someone trusted. How can the attestation server say a given hash of the initrd as a whole is good? If IMA is running from the very start, it can at least measure (and eventually appraise) every individual file in the initrd. Given this more detailed measurement list, the attestation server can verify all the components in the initrd, even when it is assembled on the untrusted system. On many embedded systems, there is no initrd, and IMA has to start measuring and appraising immediately, anyway. Perhaps there is a use case where there is a known set of initrd images, and so the bootloader's measurement of the initrd is sufficient for verification. I've not run into that situation yet. If you want an option for this use case, that's fine, (I'm all for choice) but it should not be the default for IMA. dave
On Tue, 2018-03-13 at 12:57 +0000, Safford, David (GE Global Research, US) wrote: > > > > -----Original Message----- > > From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com > > ] > > Sent: Monday, March 12, 2018 8:07 PM > > To: Mimi Zohar <zohar@linux.vnet.ibm.com>; Jiandi An [...] > > > > The key question is not whether the component could > > > > theoretically > > > > access the files but whether it actually does so. > > > > > > As much as you might think you know what is included in the > > > initramfs, IMA-measurement is your safety net, including > > > everything accessed in the TCB. > > > > The initrd *is* part of the Trusted Computing Base because it's > > part of the boot custody chain. That's really my point. If I > > don't know what's in my initrd, I've broken the chain there and IMA > > can't fix it. > > > > James > > That's exactly the point - how do you know what's in your initrd? > The initrd is normally built on the possibly compromised system in > question. The point of deploying security measures is to make sure my system isn't compromised. I realise the institutional view is "we didn't build the initrd" and my individual view is well, I built my own kernel as well, so what's the difference? But the initrd in both models is still part of the chain. > It's not signed as a whole by someone trusted. How can the > attestation server say a given hash of the initrd as a whole is good? I trust myself. I can get the hash at build time. In the same way as I sign my own kernel at build time for secure boot. > If IMA is running from the very start, it can at least measure (and > eventually appraise) every individual file in the initrd. Given this > more detailed measurement list, the attestation server can verify all > the components in the initrd, even when it is assembled on the > untrusted system. > > On many embedded systems, there is no initrd, and IMA has to start > measuring and appraising immediately, anyway. > > Perhaps there is a use case where there is a known set of initrd > images, and so the bootloader's measurement of the initrd is > sufficient for verification. I've not run into that situation yet. If > you want an option for this use case, that's fine, (I'm all for > choice) but it should not be the default for IMA. Actually, we seem to have wandered away from the main concern which was trying to select built in TPM drivers. What about a compromise: we already get the boot loader to do measurements and PCR extensions using the BIOS TPM driver, there's no reason why we can't do the same in the early kernel until a real TPM driver is found. That way IMA would have no dependency on any built in TPM driver ... is that an acceptable compromise to everyone? James
On Wed, 2018-03-14 at 07:41 -0700, James Bottomley wrote: > On Tue, 2018-03-13 at 12:57 +0000, Safford, David (GE Global Research, > US) wrote: > > > > > > -----Original Message----- > > > From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com > > > ] > > > Sent: Monday, March 12, 2018 8:07 PM > > > To: Mimi Zohar <zohar@linux.vnet.ibm.com>; Jiandi An > [...] > > > > > The key question is not whether the component could > > > > > theoretically > > > > > access the files but whether it actually does so. > > > > > > > > As much as you might think you know what is included in the > > > > initramfs, IMA-measurement is your safety net, including > > > > everything accessed in the TCB. > > > > > > The initrd *is* part of the Trusted Computing Base because it's > > > part of the boot custody chain. That's really my point. If I > > > don't know what's in my initrd, I've broken the chain there and IMA > > > can't fix it. > > > > > > James > > > > That's exactly the point - how do you know what's in your initrd? > > The initrd is normally built on the possibly compromised system in > > question. > > The point of deploying security measures is to make sure my system > isn't compromised. I realise the institutional view is "we didn't > build the initrd" and my individual view is well, I built my own kernel > as well, so what's the difference? But the initrd in both models is > still part of the chain. > > > It's not signed as a whole by someone trusted. How can the > > attestation server say a given hash of the initrd as a whole is good? > > I trust myself. I can get the hash at build time. In the same way as > I sign my own kernel at build time for secure boot. > > > If IMA is running from the very start, it can at least measure (and > > eventually appraise) every individual file in the initrd. Given this > > more detailed measurement list, the attestation server can verify all > > the components in the initrd, even when it is assembled on the > > untrusted system. > > > > On many embedded systems, there is no initrd, and IMA has to start > > measuring and appraising immediately, anyway. > > > > Perhaps there is a use case where there is a known set of initrd > > images, and so the bootloader's measurement of the initrd is > > sufficient for verification. I've not run into that situation yet. If > > you want an option for this use case, that's fine, (I'm all for > > choice) but it should not be the default for IMA. > > Actually, we seem to have wandered away from the main concern which was > trying to select built in TPM drivers. IMA selecting the generic TPM drivers has never been an issue. As I mentioned previously, this is simply a convenience. Anyone building a kernel can configure the vendor specific TPM drivers as builtin. In terms of distro's, configuring vendor specific TPMs as builtin is a TPM vandor/distro discussion. On OpenPower, we've requested the Atmel, Infineon, and Nuvoton TPM drivers be builtin by the different distro's. > What about a compromise: we > already get the boot loader to do measurements and PCR extensions using > the BIOS TPM driver, there's no reason why we can't do the same in the > early kernel until a real TPM driver is found. Your proposal requires changes to the existing boot loaders, not all of which are X86 based. Grub, to the best of my knowledge, is not interested in having anything to do with TPM based measurements. Many attempts have been made to upstream trusted boot patches, but none have been accepted. Any support would need to piggyback on the callback hooks introduced for secure boot and then be carried by the distros. As for Linux based boot loaders, the driver needs to be builtin for these measurements. So this wouldn't help you. > That way IMA would have > no dependency on any built in TPM driver ... is that an acceptable > compromise to everyone? Adding additional support for post IMA-initialization for TPM's built as kernel modules is clearly not optimal for all of the reasons provided to now and will be confusing, but could be supported. This delayed loading of the TPM needs to be clearly indicated in both the audit log and in IMA's measurement list. In terms of attestation, if a measurement policy is enabled before the TPM is loaded, any records up to the delayed TPM entry in the IMA measurement list would need to be ignored. In addition, your changes should not in any way change the existing IMA-measurement initialization. Mimi
On Wed, 2018-03-14 at 13:08 -0400, Mimi Zohar wrote: > On Wed, 2018-03-14 at 07:41 -0700, James Bottomley wrote: [...] > > What about a compromise: we > > already get the boot loader to do measurements and PCR extensions > > using the BIOS TPM driver, there's no reason why we can't do the > > same in the early kernel until a real TPM driver is found. > > Your proposal requires changes to the existing boot loaders, not all > of which are X86 based. I don't believe it does, see below. > Grub, to the best of my knowledge, is not interested in having > anything to do with TPM based measurements. Many attempts have been > made to upstream trusted boot patches, but none have been accepted. Just for the sake of accuracy, even though it has nothing to do with the current proposal, grub does actually measure the booting components. It does this via a shim protocol trick, so when grub passes the kernel to shim to verify the signature, shim also stores its measurement in the TPM boot log. > Any support would need to piggyback on the callback hooks introduced > for secure boot and then be carried by the distros. Right, that's how it does actually work today. This is more or less what made me think of the compromise: the way shim does measurements is using the EFI TPM protocol. Although this is technically a boot time UEFI driver, we can make it serve us until we're ready to load the real TPM driver, so we could write measurements to a PCR without any kernel drivers loaded. > As for Linux based boot loaders, the driver needs to be builtin for > these measurements. So this wouldn't help you. > > > > > That way IMA would have no dependency on any built in TPM driver > > ... is that an acceptable compromise to everyone? > > Adding additional support for post IMA-initialization for TPM's built > as kernel modules is clearly not optimal for all of the reasons > provided to now and will be confusing, but could be supported. This > delayed loading of the TPM needs to be clearly indicated in both the > audit log and in IMA's measurement list. Why if the measurement chain isn't broken? The way I'm thinking of implementing it, IMA wouldn't even know. What would happen is that a NULL tpm chip in tpm_pcr_read/tpm_pcr_extend would trigger the usual search for the first TPM but if none were found and we'd booted on an EFI system, we'd just use the EFI driver to do perform the operation. There's probably a bit of additional subtlety making the kernel and EFI agree which TPM they're using in a multi-TPM situation. The EFI driver isn't full featured: it only does measurement and logging, but it looks like that's all IMA needs. James > In terms of attestation, if a measurement policy is enabled before > the TPM is loaded, any records up to the delayed TPM entry in the IMA > measurement list would need to be ignored. > > In addition, your changes should not in any way change the existing > IMA-measurement initialization. > > Mimi >
On Wed, 2018-03-14 at 10:25 -0700, James Bottomley wrote: > On Wed, 2018-03-14 at 13:08 -0400, Mimi Zohar wrote: [..] > > Adding additional support for post IMA-initialization for TPM's built > > as kernel modules is clearly not optimal for all of the reasons > > provided to now and will be confusing, but could be supported. This > > delayed loading of the TPM needs to be clearly indicated in both the > > audit log and in IMA's measurement list. > > Why if the measurement chain isn't broken? The way I'm thinking of > implementing it, IMA wouldn't even know. I'm not sure this is good news. > What would happen is that a > NULL tpm chip in tpm_pcr_read/tpm_pcr_extend would trigger the usual > search for the first TPM but if none were found and we'd booted on an > EFI system, we'd just use the EFI driver to do perform the operation. If EFI is extending the TPM, will the events be added to the TPM event log or to the IMA measurement list? Up to now the IMA boot aggregate record includes PCRs from 0 - 7. With these PCRs, the boot aggregate wouldn't change when booting the same kernel. Would you change the boot-aggregate to include these other PCRs? > There's probably a bit of additional subtlety making the kernel and EFI > agree which TPM they're using in a multi-TPM situation. Agreed > The EFI driver isn't full featured: it only does measurement and > logging, but it looks like that's all IMA needs. What happens for non EFI systems, when you can't extend the TPM? Mimi
On Thu, 2018-03-15 at 12:19 -0400, Mimi Zohar wrote: > On Wed, 2018-03-14 at 10:25 -0700, James Bottomley wrote: > > > > On Wed, 2018-03-14 at 13:08 -0400, Mimi Zohar wrote: > [..] > > > > > > > > Adding additional support for post IMA-initialization for TPM's > > > built as kernel modules is clearly not optimal for all of the > > > reasons provided to now and will be confusing, but could be > > > supported. This delayed loading of the TPM needs to be clearly > > > indicated in both the audit log and in IMA's measurement list. > > > > Why if the measurement chain isn't broken? The way I'm thinking of > > implementing it, IMA wouldn't even know. > > I'm not sure this is good news. > > > What would happen is that a NULL tpm chip in > > tpm_pcr_read/tpm_pcr_extend would trigger the usual > > search for the first TPM but if none were found and we'd booted on > > an EFI system, we'd just use the EFI driver to do perform the > > operation. > > If EFI is extending the TPM, will the events be added to the TPM > event log or to the IMA measurement list? I'm not proposing any changes to the tpm_pcr_extend API. At the moment it does an extend without logging, so that's what it will do in the EFI driver case as well. That means logging is still the responsibility of the caller. > Up to now the IMA boot aggregate record includes PCRs from 0 - 7. > With these PCRs, the boot aggregate wouldn't change when booting the > same kernel. Would you change the boot-aggregate to include these > other PCRs? This is all IMA internal stuff that's up to you. All I would do is make the tpm_pcr API work with an EFI driver. That has no impact on what the PCRs return (well, unless we start using it to log early components of the kernel boot, which is a possibility). > > There's probably a bit of additional subtlety making the kernel and > > EFI agree which TPM they're using in a multi-TPM situation. > > Agreed > > > > > The EFI driver isn't full featured: it only does measurement and > > logging, but it looks like that's all IMA needs. > > What happens for non EFI systems, when you can't extend the TPM? The same as happens today if there's no TPM available: you'd get an error return. Since older bios is essentially legacy, I wouldn't propose fixing this, but the TCG does define a non-EFI BIOS interface which could theoretically be used in the same way as the BIOS one if someone with a legacy box were interested in implementing it. James
On Thu, 2018-03-15 at 10:08 -0700, James Bottomley wrote: > On Thu, 2018-03-15 at 12:19 -0400, Mimi Zohar wrote: > > If EFI is extending the TPM, will the events be added to the TPM > > event log or to the IMA measurement list? > > I'm not proposing any changes to the tpm_pcr_extend API. At the moment > it does an extend without logging, so that's what it will do in the EFI > driver case as well. That means logging is still the responsibility of > the caller. Does EFI support extending multiple TPM banks? Mimi
On Thu, 2018-03-15 at 13:14 -0400, Mimi Zohar wrote: > On Thu, 2018-03-15 at 10:08 -0700, James Bottomley wrote: > > > > On Thu, 2018-03-15 at 12:19 -0400, Mimi Zohar wrote: > > > > > > > > > If EFI is extending the TPM, will the events be added to the TPM > > > event log or to the IMA measurement list? > > > > I'm not proposing any changes to the tpm_pcr_extend API. At the > > moment it does an extend without logging, so that's what it will do > > in the EFI driver case as well. That means logging is still the > > responsibility of the caller. > > Does EFI support extending multiple TPM banks? The specs are here: https://trustedcomputinggroup.org/tcg-efi-protocol-specification/ As I said, I'm not planning to change the tpm_pcr_.. API. At the moment for a TPM2 we extend all banks in the tpm_pcr_extend() API, so that's what we'll continue to do ... including extending the sha256 banks with the sha1 hash, which seems to be our current practice. James
On Thu, 2018-03-15 at 10:29 -0700, James Bottomley wrote: > On Thu, 2018-03-15 at 13:14 -0400, Mimi Zohar wrote: > > On Thu, 2018-03-15 at 10:08 -0700, James Bottomley wrote: > > > > > > On Thu, 2018-03-15 at 12:19 -0400, Mimi Zohar wrote: > > > > > > > > > > > > > If EFI is extending the TPM, will the events be added to the TPM > > > > event log or to the IMA measurement list? > > > > > > I'm not proposing any changes to the tpm_pcr_extend API. At the > > > moment it does an extend without logging, so that's what it will do > > > in the EFI driver case as well. That means logging is still the > > > responsibility of the caller. > > > > Does EFI support extending multiple TPM banks? > > The specs are here: > > https://trustedcomputinggroup.org/tcg-efi-protocol-specification/ > > As I said, I'm not planning to change the tpm_pcr_.. API. At the > moment for a TPM2 we extend all banks in the tpm_pcr_extend() API, so > that's what we'll continue to do ... including extending the sha256 > banks with the sha1 hash, which seems to be our current practice. Thanks, what you're planning on doing is a lot clearer now. Mimi
diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig index 35ef693..6a8f677 100644 --- a/security/integrity/ima/Kconfig +++ 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 + select TCG_CRB if TCG_TPM && ACPI select TCG_IBMVTPM if TCG_TPM && PPC_PSERIES help The Trusted Computing Group(TCG) runtime Integrity
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@codeaurora.org> --- security/integrity/ima/Kconfig | 1 + 1 file changed, 1 insertion(+)