[tpm2] Re: Use PCR10 of sha256 PCR bank

[tpm2] Re: Use PCR10 of sha256 PCR bank

[nicolasoliver03]

[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]

As today, IMA is harcoded to make the boot_aggregate entry in SHA1

https://github.com/torvalds/linux/blob/ac438771ccb4479528594c7e19f2c39cf1814a86/security/integrity/ima/ima_init.c#L59

So the ima_hash=sha256 option is activated after the boot_aggregate. It is the same for me in Fedora 31. It would be nice if somebody contributed to the kernel and fixes this, or at least harcode it to sha256 :)

What I can see from you initial message is that you get all the digest from the measured boot process (PCR 0 to 7) in both SHA1 and SHA256 PCRs, which means that your BIOS to TPM interaction is working fine. In Fedora, you would see additional measurements in the PCR 8 and 9 corresponding to the digests of the components that grub2 reads (config, kernel and kernel config, and initiramfs).

But when IMA is measuring stuff, you get only PCR SHA1 digests. I think this is related to the 4.4 kernel version. The oldest kernel I used to validate IMA was a 4.17, and I am currently using 5.6. I believe there is no option to control which PCR banks IMA uses, it should measure in all the available PCR 10s by default. Is upgrading to Ubuntu 18.04 or 20.04 possible for you? Also, Ubuntu 16.04 is EOL since April 2019, so you have other good reasons to upgrade :)

[tpm2] Re: Use PCR10 of sha256 PCR bank

[nicolasoliver03]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

Great! 

Additionally in that patch, there is a tool that provides IMA event log parsing here https://github.com/initlove/attest-tools
Apparently, it requires the IBM TSS stack. 
I would be nice if the https://github.com/tpm2-software/tpm2-tools/blob/master/tools/misc/tpm2_eventlog.c tool supported the IMA event log as well

[tpm2] Re: Use PCR10 of sha256 PCR bank

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 2592 bytes --]

> > -----Original Message-----
> > From: nicolasoliver03(a)gmail.com [mailto:nicolasoliver03(a)gmail.com]
> > Sent: Friday, May 8, 2020 10:55 AM
> > To: tpm2(a)lists.01.org
> > Subject: [tpm2] Re: Use PCR10 of sha256 PCR bank
> >
> > As today, IMA is harcoded to make the boot_aggregate entry in SHA1
> >
> > https://github.com/torvalds/linux/blob/ac438771ccb4479528594c7e19f2c39
> > cf181
> > 4a86/security/integrity/ima/ima_init.c#L59
> >
> > So the ima_hash=sha256 option is activated after the boot_aggregate.
> > It is the same for me in Fedora 31. It would be nice if somebody
> > contributed to the kernel and fixes this, or at least harcode it to
> > sha256 :)
> >
> > What I can see from you initial message is that you get all the digest
> > from the measured boot process (PCR 0 to 7) in both SHA1 and SHA256
> > PCRs, which means that your BIOS to TPM interaction is working fine.
> > In Fedora, you would see additional measurements in the PCR 8 and 9
> > corresponding to the digests of the components that grub2 reads (config,
> kernel and kernel config, and initiramfs).
> >
> > But when IMA is measuring stuff, you get only PCR SHA1 digests. I
> > think this is related to the 4.4 kernel version. The oldest kernel I
> > used to validate IMA was a 4.17, and I am currently using 5.6. I
> > believe there is no option to control which PCR banks IMA uses, it
> > should measure in all the available PCR 10s by default. Is upgrading
> > to Ubuntu 18.04 or 20.04 possible for you? Also, Ubuntu 16.04 is EOL
> > since April 2019, so you have other good reasons to upgrade :)
> 
> They likely limit it because hashing things for N digests is pretty slow. However,
> the Code could be taught that if it's extending to a tpm2 chip to use sha256 and
> sha1 for The older < 1.2 chips.
> 
> I through together, an untested kernel patch here, that should at least cover that
> one Case you pointed out earlier, but their might be others, I don't know. If there
> are others It might be worth a different approach where IMA just asks what the
> best algorithm is and associates all tpm events with that algorithm, rather than
> having to do it at a bunch of spots in the code.
> Not 100% sure how IMA is internally constructed.
> 
> Here is a link to that patch if you wanna give it a go
> https://github.com/tpm2-software/tpm2-tools/issues/2009#issuecomment-
> 625961138
> 

FYI there is a patchlist on IMA already doing what we want, see:
https://lore.kernel.org/linux-integrity/20200325104712.25694-1-roberto.sassu(a)huawei.com/

Bill

[tpm2] Re: Use PCR10 of sha256 PCR bank

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 2540 bytes --]



> -----Original Message-----
> From: nicolasoliver03(a)gmail.com [mailto:nicolasoliver03(a)gmail.com]
> Sent: Friday, May 8, 2020 10:55 AM
> To: tpm2(a)lists.01.org
> Subject: [tpm2] Re: Use PCR10 of sha256 PCR bank
> 
> As today, IMA is harcoded to make the boot_aggregate entry in SHA1
> 
> https://github.com/torvalds/linux/blob/ac438771ccb4479528594c7e19f2c39cf181
> 4a86/security/integrity/ima/ima_init.c#L59
> 
> So the ima_hash=sha256 option is activated after the boot_aggregate. It is the
> same for me in Fedora 31. It would be nice if somebody contributed to the kernel
> and fixes this, or at least harcode it to sha256 :)
> 
> What I can see from you initial message is that you get all the digest from the
> measured boot process (PCR 0 to 7) in both SHA1 and SHA256 PCRs, which means
> that your BIOS to TPM interaction is working fine. In Fedora, you would see
> additional measurements in the PCR 8 and 9 corresponding to the digests of the
> components that grub2 reads (config, kernel and kernel config, and initiramfs).
> 
> But when IMA is measuring stuff, you get only PCR SHA1 digests. I think this is
> related to the 4.4 kernel version. The oldest kernel I used to validate IMA was a
> 4.17, and I am currently using 5.6. I believe there is no option to control which PCR
> banks IMA uses, it should measure in all the available PCR 10s by default. Is
> upgrading to Ubuntu 18.04 or 20.04 possible for you? Also, Ubuntu 16.04 is EOL
> since April 2019, so you have other good reasons to upgrade :)

They likely limit it because hashing things for N digests is pretty slow. However, the
Code could be taught that if it's extending to a tpm2 chip to use sha256 and sha1 for
The older < 1.2 chips. 

I through together, an untested kernel patch here, that should at least cover that one
Case you pointed out earlier, but their might be others, I don't know. If there are others
It might be worth a different approach where IMA just asks what the best algorithm is and
associates all tpm events with that algorithm, rather than having to do it at a bunch of spots
in the code.
Not 100% sure how IMA is internally constructed.

Here is a link to that patch if you wanna give it a go
https://github.com/tpm2-software/tpm2-tools/issues/2009#issuecomment-625961138

> _______________________________________________
> tpm2 mailing list -- tpm2(a)lists.01.org
> To unsubscribe send an email to tpm2-leave(a)lists.01.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[tpm2] Re: Use PCR10 of sha256 PCR bank

[@ 2020-05-08 17:27 UTC (permalink / raw)]

[-- Attachment #1: Type: text/plain, Size: 142 bytes --]

Thank you, Nicolas.

Your reasoning makes total sense to me.
I'll try upgrading my ubuntu to check if this issue is solved.

Best regards

[tpm2] Re: Use PCR10 of sha256 PCR bank

[@ 2020-05-08 1:53 UTC (permalink / raw)]

[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]

Inspecting the measurements collected by IMA I just saw that boot aggregate is created with sha1, but then all measurements are extended with sha256.

10 e54afd0b8be44bda96d19b3ba154abf0122f80f0 ima-ng sha1:8bec961a62ee4589db6506002d974fee2d5cf2c6 boot_aggregate
10 71f5a9db669451d369635f6ff3a2aeb623ba5282 ima-ng sha256:4cadb747c2e6d894228198fe9091d3f289c704edf82ddbd5945c54ec847d0bb6 /init
10 b2a44047548e6ec6791fc2455fdf70beebac20d0 ima-ng sha256:c3b773ac00b68d908431b73e68c1b5f4229748dd386f651b6503198d3bfc9780 /bin/sh
10 2e200610d43da1cbd2a41dc6fe0b48b43faa4fcc ima-ng sha256:0f754eab280e5ff0b65c46bdd1cc16e8aff944c834379df2632cd5f261afe3bb /lib/x86_64-linux-gnu/ld-2.23.so
10 c50746154c54730caaaae10fe2cf43e2d34c243f ima-ng sha256:6261d3a53a3ee7de728effa63be8ddbc4daecfdf2e40951cd04b5e8d091b1a9b /etc/ld.so.cache
10 e16f2cc0281caf744454631d937bff59641c455d ima-ng sha256:74ca69ada4429ae5fce87f7e3addb56f1b53964599e8526244fecd164b3c4b44 /lib/x86_64-linux-gnu/libc-2.23.so
10 0f8b2256c6159adfec34fc26b0f70f62b189e9a6 ima-ng sha256:91f2413151b7b0451ce0b6cedc7e5919931acf792d9a26645c0deb3bc230d9fe /conf/arch.conf
10 37b7648c357ee449e136fc15a7a0ffcc50ef46a9 ima-ng sha256:3ab885510eee04a49f638e98226f5bd96ed707da20d0e8a937c13ce33a889e1b /conf/initramfs.conf
10 6f56f95b5b78bc076ebdd77242a16203c44c5813 ima-ng sha256:ed5f0d4f1363d1a9fc7967b9dba2f0e0db75b88ad39fd1d0f5a6efd3f2d170dc /scripts/functions

[tpm2] Re: Use PCR10 of sha256 PCR bank

[eduardolfalcao]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

> Hi Eduardo!

Hi Nicolas. :)

> 
> Glad to know there is somebody else playing the IMA game :)
> 
> For my case, it happens automatically on any Fedora host since F31.
> Also, the IMA measurement logic is kernel responsibility, tpm2-software only allows you to
> read what the kernel already did.  

Then, I assume there is something else to be configured on my OS.
Is that what you think?

> 
> Which Linux flavor are you using?

It is Ubuntu 16.04.6 LTS.

ubuntu(a)ubuntu:~$ uname -a
Linux ubuntu 4.4.0-178-generic #208-Ubuntu SMP Sun Apr 5 23:45:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
ubuntu(a)ubuntu:~$ cat /etc/os-release
NAME="Ubuntu"
VERSION="16.04.6 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.6 LTS"
VERSION_ID="16.04"

Thanks for the help.

[tpm2] Re: Use PCR10 of sha256 PCR bank

[nicolasoliver03]

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]

Hi Eduardo!

Glad to know there is somebody else playing the IMA game :)

For my case, it happens automatically on any Fedora host since F31.
Also, the IMA measurement logic is kernel responsibility, tpm2-software only allows you to read what the kernel already did.  

Which Linux flavor are you using?