| Message ID | 20200527071434.28574-1-pvorel@suse.cz (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [LTP,v2,1/1] ima_tpm.sh: Fix for calculating boot aggregate | expand |
Hi Petr, On Wed, 2020-05-27 at 09:14 +0200, Petr Vorel wrote: > Fixes test for kernel commit: 6f1a1d103b48 ima: ("Switch to > ima_hash_algo for boot aggregate") from current linux-integrity tree. > > Tests was failing, because it expect SHA1 hash, but for TPM 2.0 is > now used IMA default hash algorithm (by default default SHA256). > This is similar for entries in IMA measurement list so we can reuse > already existing code. > > Signed-off-by: Petr Vorel <pvorel@suse.cz> > --- > changes v1->v2: > * removing global variables from get_algorithm_digest (hopefully it's > less ugly) > > Tested only on VM. Can anybody test it on real HW? With just this change, the ima_tpm.sh test is failing. I assume it is failing because it is reading the SHA1 TPM bank, not the SHA256 bank to calculate the boot_aggregate hash. ima_tpm 1 TINFO: timeout per run is 0h 5m 0s ima_tpm 1 TINFO: IMA kernel config: ima_tpm 1 TINFO: CONFIG_IMA=y ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10 ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng" ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256" ima_tpm 1 TINFO: CONFIG_IMA_WRITE_POLICY=y ima_tpm 1 TINFO: CONFIG_IMA_READ_POLICY=y ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y ima_tpm 1 TINFO: CONFIG_IMA_ARCH_POLICY=y ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y ima_tpm 1 TINFO: CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y ima_tpm 1 TINFO: CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc3+.signed root=UUID=119f1a79-c391-4e37-905d-3a503284cadb ro quiet splash ima-policy=tcb ima_tpm 1 TINFO: verify boot aggregate ima_tpm 1 TINFO: used algorithm: sha256 ima_tpm 1 TINFO: IMA boot aggregate: 'b2341e4ccea25be7fa750830fb5fdf4bef1c44a4' ima_tpm 1 TFAIL: bios boot aggregate does not match IMA boot aggregate (3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b) ima_tpm 2 TINFO: verify PCR values ima_tpm 2 TINFO: evmctl version: evmctl 1.2 ima_tpm 2 TCONF: TPM Hardware Support not enabled in kernel or no TPM chip found ima_tpm 3 TINFO: AppArmor enabled, this may affect test results ima_tpm 3 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root) ima_tpm 3 TINFO: loaded AppArmor profiles: none Summary: passed 0 failed 1 skipped 1 warnings 0 # head -1 /sys/kernel/security/ima/ascii_runtime_measurements 10 a3132d2501128ff527171658d40d8deb61e2292b ima-ng sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 b boot_aggregate The ima-evm-utils next-testing branch has code to calculate the boot_aggregate based on multiple banks. # evmctl ima_boot_aggregate sha1:4cf3d105b1a1a41b951cc6431f0801c01fe50b24 sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b There's also a new test to verify the boot_aggregate. $ VERBOSE=1 make check TESTS=boog_aggregate.test Both need some review and testing before being released. thanks, Mimi
Hi Mimi, thanks a lot for testing! > On Wed, 2020-05-27 at 09:14 +0200, Petr Vorel wrote: > > Fixes test for kernel commit: 6f1a1d103b48 ima: ("Switch to > > ima_hash_algo for boot aggregate") from current linux-integrity tree. > > Tests was failing, because it expect SHA1 hash, but for TPM 2.0 is > > now used IMA default hash algorithm (by default default SHA256). > > This is similar for entries in IMA measurement list so we can reuse > > already existing code. > > Signed-off-by: Petr Vorel <pvorel@suse.cz> > > --- > > changes v1->v2: > > * removing global variables from get_algorithm_digest (hopefully it's > > less ugly) > > Tested only on VM. Can anybody test it on real HW? > With just this change, the ima_tpm.sh test is failing. I assume it is > failing because it is reading the SHA1 TPM bank, not the SHA256 bank > to calculate the boot_aggregate hash. First question: is it correct to take sha256? Because on my test below it's reading sha1, because that's the content of /sys/kernel/security/ima/ascii_runtime_measurements I thought just kernel commit: 6f1a1d103b48 ima: ("Switch to ima_hash_algo for boot aggregate") from current linux-integrity tree is needed, but I tested it on b59fda449cf0 ("ima: Set again build_ima_appraise variable") (i.e. having all Robeto's ima patches, missing just last 2 commits from next-integrity head). What is needed to get your setup? We both have CONFIG_IMA_DEFAULT_HASH_SHA256=y and CONFIG_IMA_DEFAULT_HASH="sha256". > ima_tpm 1 TINFO: timeout per run is 0h 5m 0s > ima_tpm 1 TINFO: IMA kernel config: > ima_tpm 1 TINFO: CONFIG_IMA=y > ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10 > ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y > ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng" > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256" > ima_tpm 1 TINFO: CONFIG_IMA_WRITE_POLICY=y > ima_tpm 1 TINFO: CONFIG_IMA_READ_POLICY=y > ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y > ima_tpm 1 TINFO: CONFIG_IMA_ARCH_POLICY=y > ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y > ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y > ima_tpm 1 TINFO: CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y > ima_tpm 1 TINFO: CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y > ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc3+.signed root=UUID=119f1a79-c391-4e37-905d-3a503284cadb ro quiet splash ima-policy=tcb > ima_tpm 1 TINFO: verify boot aggregate > ima_tpm 1 TINFO: used algorithm: sha256 > ima_tpm 1 TINFO: IMA boot aggregate: 'b2341e4ccea25be7fa750830fb5fdf4bef1c44a4' > ima_tpm 1 TFAIL: bios boot aggregate does not match IMA boot aggregate (3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b) > ima_tpm 2 TINFO: verify PCR values > ima_tpm 2 TINFO: evmctl version: evmctl 1.2 > ima_tpm 2 TCONF: TPM Hardware Support not enabled in kernel or no TPM chip found > ima_tpm 3 TINFO: AppArmor enabled, this may affect test results > ima_tpm 3 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root) > ima_tpm 3 TINFO: loaded AppArmor profiles: none > Summary: > passed 0 > failed 1 > skipped 1 > warnings 0 BTW my results on custom kernel: ima_tpm 1 TINFO: timeout per run is 0h 5m 0s ima_tpm 1 TINFO: IMA kernel config: ima_tpm 1 TINFO: CONFIG_IMA=y ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10 ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng" ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256" ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_BOOTPARAM=y ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_MODSIG=y ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y ima_tpm 1 TINFO: CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.3.18-20-default root=/dev/mapper/system-root crashkernel=121M,high crashkernel=72M,low isofrom=/dev/disk/by-uuid/3271-1AD6:/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso isofrom_device=/dev/disk/by-uuid/3271-1AD6 isofrom_system=/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso loader=syslinux quiet resume=/dev/system/swap splash=silent quiet showopts ima_tpm 1 TINFO: IMA kernel config: ima_tpm 1 TINFO: CONFIG_IMA=y ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10 ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng" ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256" ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_BOOTPARAM=y ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_MODSIG=y ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y ima_tpm 1 TINFO: CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.3.18-20-default root=/dev/mapper/system-root crashkernel=121M,high crashkernel=72M,low isofrom=/dev/disk/by-uuid/3271-1AD6:/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso isofrom_device=/dev/disk/by-uuid/3271-1AD6 isofrom_system=/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso loader=syslinux quiet resume=/dev/system/swap splash=silent quiet showopts ima_tpm 1 TINFO: verify boot aggregate ima_tpm 1 TINFO: used algorithm: sha1 ima_tpm 1 TINFO: IMA boot aggregate: '1172f0990296510ed39403b4f1de83c82e093aae' ima_tpm 1 TPASS: bios boot aggregate matches IMA boot aggregate (1172f0990296510ed39403b4f1de83c82e093aae) ima_tpm 2 TINFO: verify PCR values ima_tpm 2 TINFO: evmctl version: evmctl 1.2.1 ima_tpm 2 TINFO: new PCRS path, evmctl >= 1.1 required ima_tpm 2 TINFO: verify PCR (Process Control Register) ima_tpm 2 TPASS: aggregate PCR value matches real PCR value Summary: passed 2 failed 0 skipped 0 warnings 0 > # head -1 /sys/kernel/security/ima/ascii_runtime_measurements > 10 a3132d2501128ff527171658d40d8deb61e2292b ima-ng > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 > b boot_aggregate mine: 10 c125a1d3684a9737f20f6c1bc880782fae60fb28 ima-ng sha1:1172f0990296510ed39403b4f1de83c82e093aae boot_aggregate > The ima-evm-utils next-testing branch has code to calculate the > boot_aggregate based on multiple banks. I see, 696bf0b ("ima-evm-utils: calculate the digests for multiple TPM banks") I wonder whether it's reasonable trying to port that to ima_boot_aggregate.c or just depend on evmctl. External dependencies are sometimes complicated, but for IMA I incline to just require evmctl. > # evmctl ima_boot_aggregate > sha1:4cf3d105b1a1a41b951cc6431f0801c01fe50b24 > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b Thus obviously evmctl (from next-testing) also gets only sha1 ./src/evmctl ima_boot_aggregate sha1:1172f0990296510ed39403b4f1de83c82e093aae > There's also a new test to verify the boot_aggregate. > $ VERBOSE=1 make check TESTS=boog_aggregate.test BTW I got some errors ... make check-TESTS make[2]: Entering directory '/home/foo/ima-evm-utils/tests' make[3]: Entering directory '/home/foo/ima-evm-utils/tests' make[4]: Entering directory '/home/foo/ima-evm-utils/tests' make[4]: Nothing to be done for 'boog_aggregate.log'. make[4]: Leaving directory '/home/foo/ima-evm-utils/tests' fatal: making test-suite.log: failed to create boog_aggregate.trs fatal: making test-suite.log: failed to create boog_aggregate.log make[3]: *** [Makefile:516: test-suite.log] Error 1 make[3]: Leaving directory '/home/foo/ima-evm-utils/tests' make[2]: *** [Makefile:625: check-TESTS] Error 2 make[2]: Leaving directory '/home/foo/ima-evm-utils/tests' make[1]: *** [Makefile:692: check-am] Error 2 make[1]: Leaving directory '/home/foo/ima-evm-utils/tests' make: *** [Makefile:514: check-recursive] Error 1 > Both need some review and testing before being released. Any estimation when code is released? Kind regards, Petr
On Thu, 2020-05-28 at 16:07 +0200, Petr Vorel wrote: > Hi Mimi, > > thanks a lot for testing! > > > On Wed, 2020-05-27 at 09:14 +0200, Petr Vorel wrote: > > > Fixes test for kernel commit: 6f1a1d103b48 ima: ("Switch to > > > ima_hash_algo for boot aggregate") from current linux-integrity tree. > > > > Tests was failing, because it expect SHA1 hash, but for TPM 2.0 is > > > now used IMA default hash algorithm (by default default SHA256). > > > This is similar for entries in IMA measurement list so we can reuse > > > already existing code. > > > > Signed-off-by: Petr Vorel <pvorel@suse.cz> > > > --- > > > changes v1->v2: > > > * removing global variables from get_algorithm_digest (hopefully it's > > > less ugly) > > > > Tested only on VM. Can anybody test it on real HW? > > > With just this change, the ima_tpm.sh test is failing. I assume it is > > failing because it is reading the SHA1 TPM bank, not the SHA256 bank > > to calculate the boot_aggregate hash. > First question: is it correct to take sha256? Because on my test below it's > reading sha1, because that's the content of /sys/kernel/security/ima/ascii_runtime_measurements > > I thought just kernel commit: 6f1a1d103b48 ima: ("Switch to ima_hash_algo for > boot aggregate") from current linux-integrity tree is needed, but I tested it on > b59fda449cf0 ("ima: Set again build_ima_appraise variable") (i.e. having all > Robeto's ima patches, missing just last 2 commits from next-integrity head). > What is needed to get your setup? This isn't a configuration problem, but an issue of reading PCRs and calculating the TPM bank appropriate boot_aggregate. If you're calculating a sha256 boot_aggregate, then the test needs to read and calculate the boot_aggregate by reading the SHA256 TPM bank. > We both have CONFIG_IMA_DEFAULT_HASH_SHA256=y and CONFIG_IMA_DEFAULT_HASH="sha256". > > > ima_tpm 1 TINFO: timeout per run is 0h 5m 0s > > ima_tpm 1 TINFO: IMA kernel config: > > ima_tpm 1 TINFO: CONFIG_IMA=y > > ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10 > > ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y > > ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y > > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng" > > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y > > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256" > > ima_tpm 1 TINFO: CONFIG_IMA_WRITE_POLICY=y > > ima_tpm 1 TINFO: CONFIG_IMA_READ_POLICY=y > > ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y > > ima_tpm 1 TINFO: CONFIG_IMA_ARCH_POLICY=y > > ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y > > ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y > > ima_tpm 1 TINFO: CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y > > ima_tpm 1 TINFO: CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y > > ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc3+.signed root=UUID=119f1a79-c391-4e37-905d-3a503284cadb ro quiet splash ima-policy=tcb > > ima_tpm 1 TINFO: verify boot aggregate > > ima_tpm 1 TINFO: used algorithm: sha256 > > ima_tpm 1 TINFO: IMA boot aggregate: 'b2341e4ccea25be7fa750830fb5fdf4bef1c44a4' > > ima_tpm 1 TFAIL: bios boot aggregate does not match IMA boot aggregate (3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b) > > ima_tpm 2 TINFO: verify PCR values > > ima_tpm 2 TINFO: evmctl version: evmctl 1.2 > > ima_tpm 2 TCONF: TPM Hardware Support not enabled in kernel or no TPM chip found > > ima_tpm 3 TINFO: AppArmor enabled, this may affect test results > > ima_tpm 3 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root) > > ima_tpm 3 TINFO: loaded AppArmor profiles: none > > > Summary: > > passed 0 > > failed 1 > > skipped 1 > > warnings 0 > > > BTW my results on custom kernel: > ima_tpm 1 TINFO: timeout per run is 0h 5m 0s > ima_tpm 1 TINFO: IMA kernel config: > ima_tpm 1 TINFO: CONFIG_IMA=y > ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10 > ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y > ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng" > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256" > ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y > ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_BOOTPARAM=y > ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_MODSIG=y > ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y > ima_tpm 1 TINFO: CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y > ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.3.18-20-default root=/dev/mapper/system-root crashkernel=121M,high crashkernel=72M,low isofrom=/dev/disk/by-uuid/3271-1AD6:/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso isofrom_device=/dev/disk/by-uuid/3271-1AD6 isofrom_system=/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso loader=syslinux quiet resume=/dev/system/swap splash=silent quiet showopts > ima_tpm 1 TINFO: IMA kernel config: > ima_tpm 1 TINFO: CONFIG_IMA=y > ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10 > ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y > ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng" > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256" > ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y > ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_BOOTPARAM=y > ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_MODSIG=y > ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y > ima_tpm 1 TINFO: CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y > ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.3.18-20-default root=/dev/mapper/system-root crashkernel=121M,high crashkernel=72M,low isofrom=/dev/disk/by-uuid/3271-1AD6:/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso isofrom_device=/dev/disk/by-uuid/3271-1AD6 isofrom_system=/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso loader=syslinux quiet resume=/dev/system/swap splash=silent quiet showopts > ima_tpm 1 TINFO: verify boot aggregate > ima_tpm 1 TINFO: used algorithm: sha1 > ima_tpm 1 TINFO: IMA boot aggregate: '1172f0990296510ed39403b4f1de83c82e093aae' > ima_tpm 1 TPASS: bios boot aggregate matches IMA boot aggregate (1172f0990296510ed39403b4f1de83c82e093aae) > ima_tpm 2 TINFO: verify PCR values > ima_tpm 2 TINFO: evmctl version: evmctl 1.2.1 > ima_tpm 2 TINFO: new PCRS path, evmctl >= 1.1 required > ima_tpm 2 TINFO: verify PCR (Process Control Register) > ima_tpm 2 TPASS: aggregate PCR value matches real PCR value > > Summary: > passed 2 > failed 0 > skipped 0 > warnings 0 > > > > # head -1 /sys/kernel/security/ima/ascii_runtime_measurements > > > 10 a3132d2501128ff527171658d40d8deb61e2292b ima-ng > > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 > > b boot_aggregate > > mine: > 10 c125a1d3684a9737f20f6c1bc880782fae60fb28 ima-ng sha1:1172f0990296510ed39403b4f1de83c82e093aae boot_aggregate > > > The ima-evm-utils next-testing branch has code to calculate the > > boot_aggregate based on multiple banks. > I see, 696bf0b ("ima-evm-utils: calculate the digests for multiple TPM banks") > I wonder whether it's reasonable trying to port that to ima_boot_aggregate.c or > just depend on evmctl. External dependencies are sometimes complicated, but for > IMA I incline to just require evmctl. Unlike TPM 1.2, the TPM 2.0 device driver doesn't export the TPM PCRs. Not only would you have a dependency on ima-evm-utils, but also on a userspace application(s) for reading the TPM PCRs. That dependency exists whether you're using evmctl to calculate the boot_aggregate or doing it yourself. > > > # evmctl ima_boot_aggregate > > > sha1:4cf3d105b1a1a41b951cc6431f0801c01fe50b24 > > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b > > Thus obviously evmctl (from next-testing) also gets only sha1 > ./src/evmctl ima_boot_aggregate > sha1:1172f0990296510ed39403b4f1de83c82e093aae > > > There's also a new test to verify the boot_aggregate. > > > $ VERBOSE=1 make check TESTS=boog_aggregate.test > BTW I got some errors > ... > make check-TESTS > make[2]: Entering directory '/home/foo/ima-evm-utils/tests' > make[3]: Entering directory '/home/foo/ima-evm-utils/tests' > make[4]: Entering directory '/home/foo/ima-evm-utils/tests' > make[4]: Nothing to be done for 'boog_aggregate.log'. > make[4]: Leaving directory '/home/foo/ima-evm-utils/tests' > fatal: making test-suite.log: failed to create boog_aggregate.trs > fatal: making test-suite.log: failed to create boog_aggregate.log > make[3]: *** [Makefile:516: test-suite.log] Error 1 > make[3]: Leaving directory '/home/foo/ima-evm-utils/tests' > make[2]: *** [Makefile:625: check-TESTS] Error 2 > make[2]: Leaving directory '/home/foo/ima-evm-utils/tests' > make[1]: *** [Makefile:692: check-am] Error 2 > make[1]: Leaving directory '/home/foo/ima-evm-utils/tests' > make: *** [Makefile:514: check-recursive] Error 1 [Cc'ing Vitaly] The boot_aggregate.trs and boot_aggregate.log files are being created in the tests/ directory. Is that directory read-only? > > > Both need some review and testing before being released. > Any estimation when code is released? Probably not before the next open window, but definitely before it is released. Mimi
Hi Mimi, ... > > > With just this change, the ima_tpm.sh test is failing. I assume it is > > > failing because it is reading the SHA1 TPM bank, not the SHA256 bank > > > to calculate the boot_aggregate hash. > > First question: is it correct to take sha256? Because on my test below it's > > reading sha1, because that's the content of /sys/kernel/security/ima/ascii_runtime_measurements > > I thought just kernel commit: 6f1a1d103b48 ima: ("Switch to ima_hash_algo for > > boot aggregate") from current linux-integrity tree is needed, but I tested it on > > b59fda449cf0 ("ima: Set again build_ima_appraise variable") (i.e. having all > > Robeto's ima patches, missing just last 2 commits from next-integrity head). > > What is needed to get your setup? > This isn't a configuration problem, but an issue of reading PCRs and > calculating the TPM bank appropriate boot_aggregate. If you're > calculating a sha256 boot_aggregate, then the test needs to read and > calculate the boot_aggregate by reading the SHA256 TPM bank. OK, I tested it on TPM 1.2 (no TPM 2.0 available atm). I guess you have TPM 2.0, that's why I didn't spot this issue. To sum that: my patch is required for any system without physical TPM with with kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel version), because TPM 1.2 supports sha1 only boot aggregate. But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with this patch, but also on current version in master, right? As you have sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway. So this patch would help at least testing on VM without vTPM. ... > > > The ima-evm-utils next-testing branch has code to calculate the > > > boot_aggregate based on multiple banks. > > I see, 696bf0b ("ima-evm-utils: calculate the digests for multiple TPM banks") > > I wonder whether it's reasonable trying to port that to ima_boot_aggregate.c or > > just depend on evmctl. External dependencies are sometimes complicated, but for > > IMA I incline to just require evmctl. > Unlike TPM 1.2, the TPM 2.0 device driver doesn't export the TPM PCRs. > Not only would you have a dependency on ima-evm-utils, but also on a > userspace application(s) for reading the TPM PCRs. That dependency > exists whether you're using evmctl to calculate the boot_aggregate or > doing it yourself. Hm, things get complicated. Yep I remember your patch to skip verifying TPM 2.0 PCR values https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/ At least thanks to Jerry Snitselaar since v5.6 we have /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also /sys/class/tpm/tpm0/device/description for older kernels). BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2, not sure if it indicate TPM 1.2, but I wouldn't rely on that. ... > > > There's also a new test to verify the boot_aggregate. > > > $ VERBOSE=1 make check TESTS=boog_aggregate.test > > BTW I got some errors > > ... > > make check-TESTS > > make[2]: Entering directory '/home/foo/ima-evm-utils/tests' > > make[3]: Entering directory '/home/foo/ima-evm-utils/tests' > > make[4]: Entering directory '/home/foo/ima-evm-utils/tests' > > make[4]: Nothing to be done for 'boog_aggregate.log'. > > make[4]: Leaving directory '/home/foo/ima-evm-utils/tests' > > fatal: making test-suite.log: failed to create boog_aggregate.trs > > fatal: making test-suite.log: failed to create boog_aggregate.log > > make[3]: *** [Makefile:516: test-suite.log] Error 1 > > make[3]: Leaving directory '/home/foo/ima-evm-utils/tests' > > make[2]: *** [Makefile:625: check-TESTS] Error 2 > > make[2]: Leaving directory '/home/foo/ima-evm-utils/tests' > > make[1]: *** [Makefile:692: check-am] Error 2 > > make[1]: Leaving directory '/home/foo/ima-evm-utils/tests' > > make: *** [Makefile:514: check-recursive] Error 1 > [Cc'ing Vitaly] > The boot_aggregate.trs and boot_aggregate.log files are being created > in the tests/ directory. Is that directory read-only? Yes, drwxr-xr-x. Testing on fresh clone and issue persists. > > > Both need some review and testing before being released. > > Any estimation when code is released? > Probably not before the next open window, but definitely before it is > released. Thanks for info. Kind regards, Petr
On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote: > Hi Mimi, > ... > > > > With just this change, the ima_tpm.sh test is failing. I assume it is > > > > failing because it is reading the SHA1 TPM bank, not the SHA256 bank > > > > to calculate the boot_aggregate hash. > > > First question: is it correct to take sha256? Because on my test below it's > > > reading sha1, because that's the content of /sys/kernel/security/ima/ascii_runtime_measurements > > > > I thought just kernel commit: 6f1a1d103b48 ima: ("Switch to ima_hash_algo for > > > boot aggregate") from current linux-integrity tree is needed, but I tested it on > > > b59fda449cf0 ("ima: Set again build_ima_appraise variable") (i.e. having all > > > Robeto's ima patches, missing just last 2 commits from next-integrity head). > > > What is needed to get your setup? > > > This isn't a configuration problem, but an issue of reading PCRs and > > calculating the TPM bank appropriate boot_aggregate. If you're > > calculating a sha256 boot_aggregate, then the test needs to read and > > calculate the boot_aggregate by reading the SHA256 TPM bank. > OK, I tested it on TPM 1.2 (no TPM 2.0 available atm). > I guess you have TPM 2.0, that's why I didn't spot this issue. > > To sum that: my patch is required for any system without physical TPM with with > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel > version), because TPM 1.2 supports sha1 only boot aggregate. > > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with > this patch, but also on current version in master, right? As you have > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway. > So this patch would help at least testing on VM without vTPM. > If we consider to delay this change until we have the ima-evm-utils released with the ima_boot_aggregate + make this test dependent on both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could have the test fixed for TPM1.2 && no-TPM cases until we get the full support for multiple banks? > ... > > > > The ima-evm-utils next-testing branch has code to calculate the > > > > boot_aggregate based on multiple banks. > > > I see, 696bf0b ("ima-evm-utils: calculate the digests for multiple TPM banks") > > > I wonder whether it's reasonable trying to port that to ima_boot_aggregate.c or > > > just depend on evmctl. External dependencies are sometimes complicated, but for > > > IMA I incline to just require evmctl. > > > Unlike TPM 1.2, the TPM 2.0 device driver doesn't export the TPM PCRs. > > Not only would you have a dependency on ima-evm-utils, but also on a > > userspace application(s) for reading the TPM PCRs. That dependency > > exists whether you're using evmctl to calculate the boot_aggregate or > > doing it yourself. > Hm, things get complicated. > Yep I remember your patch to skip verifying TPM 2.0 PCR values > https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/ > At least thanks to Jerry Snitselaar since v5.6 we have > /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also > /sys/class/tpm/tpm0/device/description for older kernels). > > BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2, > not sure if it indicate TPM 1.2, but I wouldn't rely on that. > IIUC 'tpm_version_major' should be the only safe reference of the actual TCG spec version being implemented by the hw TPM, in a sysfs standard output. > ... > > > > There's also a new test to verify the boot_aggregate. > > > > > $ VERBOSE=1 make check TESTS=boog_aggregate.test > > > BTW I got some errors > > > ... > > > make check-TESTS > > > make[2]: Entering directory '/home/foo/ima-evm-utils/tests' > > > make[3]: Entering directory '/home/foo/ima-evm-utils/tests' > > > make[4]: Entering directory '/home/foo/ima-evm-utils/tests' > > > make[4]: Nothing to be done for 'boog_aggregate.log'. > > > make[4]: Leaving directory '/home/foo/ima-evm-utils/tests' > > > fatal: making test-suite.log: failed to create boog_aggregate.trs > > > fatal: making test-suite.log: failed to create boog_aggregate.log > > > make[3]: *** [Makefile:516: test-suite.log] Error 1 > > > make[3]: Leaving directory '/home/foo/ima-evm-utils/tests' > > > make[2]: *** [Makefile:625: check-TESTS] Error 2 > > > make[2]: Leaving directory '/home/foo/ima-evm-utils/tests' > > > make[1]: *** [Makefile:692: check-am] Error 2 > > > make[1]: Leaving directory '/home/foo/ima-evm-utils/tests' > > > make: *** [Makefile:514: check-recursive] Error 1 > > > [Cc'ing Vitaly] > > > The boot_aggregate.trs and boot_aggregate.log files are being created > > in the tests/ directory. Is that directory read-only? > Yes, drwxr-xr-x. Testing on fresh clone and issue persists. > Yes, same thing here.. but didn't really check the reason for that. Will take a time later to see what's happening. > > > > Both need some review and testing before being released. > > > Any estimation when code is released? > > > Probably not before the next open window, but definitely before it is > > released. > Thanks for info. >
On Mon, Jun 15, 2020 at 04:41:34PM -0300, Bruno Meneguele wrote: > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote: > > Hi Mimi, > > ... > > > > > With just this change, the ima_tpm.sh test is failing. I assume it is > > > > > failing because it is reading the SHA1 TPM bank, not the SHA256 bank > > > > > to calculate the boot_aggregate hash. > > > > First question: is it correct to take sha256? Because on my test below it's > > > > reading sha1, because that's the content of /sys/kernel/security/ima/ascii_runtime_measurements > > > > > > I thought just kernel commit: 6f1a1d103b48 ima: ("Switch to ima_hash_algo for > > > > boot aggregate") from current linux-integrity tree is needed, but I tested it on > > > > b59fda449cf0 ("ima: Set again build_ima_appraise variable") (i.e. having all > > > > Robeto's ima patches, missing just last 2 commits from next-integrity head). > > > > What is needed to get your setup? > > > > > This isn't a configuration problem, but an issue of reading PCRs and > > > calculating the TPM bank appropriate boot_aggregate. If you're > > > calculating a sha256 boot_aggregate, then the test needs to read and > > > calculate the boot_aggregate by reading the SHA256 TPM bank. > > OK, I tested it on TPM 1.2 (no TPM 2.0 available atm). > > I guess you have TPM 2.0, that's why I didn't spot this issue. > > > > To sum that: my patch is required for any system without physical TPM with with > > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel > > version), because TPM 1.2 supports sha1 only boot aggregate. > > > > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with > > this patch, but also on current version in master, right? As you have > > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway. > > So this patch would help at least testing on VM without vTPM. > > > > If we consider to delay this change until we have the ima-evm-utils > released with the ima_boot_aggregate + make this test dependent on > both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in > case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could > have the test fixed for TPM1.2 && no-TPM cases until we get the full > support for multiple banks? > > > ... > > > > > The ima-evm-utils next-testing branch has code to calculate the > > > > > boot_aggregate based on multiple banks. > > > > I see, 696bf0b ("ima-evm-utils: calculate the digests for multiple TPM banks") > > > > I wonder whether it's reasonable trying to port that to ima_boot_aggregate.c or > > > > just depend on evmctl. External dependencies are sometimes complicated, but for > > > > IMA I incline to just require evmctl. > > > > > Unlike TPM 1.2, the TPM 2.0 device driver doesn't export the TPM PCRs. > > > Not only would you have a dependency on ima-evm-utils, but also on a > > > userspace application(s) for reading the TPM PCRs. That dependency > > > exists whether you're using evmctl to calculate the boot_aggregate or > > > doing it yourself. > > Hm, things get complicated. > > Yep I remember your patch to skip verifying TPM 2.0 PCR values > > https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/ > > At least thanks to Jerry Snitselaar since v5.6 we have > > /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also > > /sys/class/tpm/tpm0/device/description for older kernels). > > > > BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2, > > not sure if it indicate TPM 1.2, but I wouldn't rely on that. > > > > IIUC 'tpm_version_major' should be the only safe reference of the actual > TCG spec version being implemented by the hw TPM, in a sysfs standard > output. > > > ... > > > > > There's also a new test to verify the boot_aggregate. > > > > > > > $ VERBOSE=1 make check TESTS=boog_aggregate.test ^^^^ boot That's the issue :). > > > > BTW I got some errors > > > > ... > > > > make check-TESTS > > > > make[2]: Entering directory '/home/foo/ima-evm-utils/tests' > > > > make[3]: Entering directory '/home/foo/ima-evm-utils/tests' > > > > make[4]: Entering directory '/home/foo/ima-evm-utils/tests' > > > > make[4]: Nothing to be done for 'boog_aggregate.log'. > > > > make[4]: Leaving directory '/home/foo/ima-evm-utils/tests' > > > > fatal: making test-suite.log: failed to create boog_aggregate.trs > > > > fatal: making test-suite.log: failed to create boog_aggregate.log > > > > make[3]: *** [Makefile:516: test-suite.log] Error 1 > > > > make[3]: Leaving directory '/home/foo/ima-evm-utils/tests' > > > > make[2]: *** [Makefile:625: check-TESTS] Error 2 > > > > make[2]: Leaving directory '/home/foo/ima-evm-utils/tests' > > > > make[1]: *** [Makefile:692: check-am] Error 2 > > > > make[1]: Leaving directory '/home/foo/ima-evm-utils/tests' > > > > make: *** [Makefile:514: check-recursive] Error 1 > > > > > [Cc'ing Vitaly] > > > > > The boot_aggregate.trs and boot_aggregate.log files are being created > > > in the tests/ directory. Is that directory read-only? > > Yes, drwxr-xr-x. Testing on fresh clone and issue persists. > > > > Yes, same thing here.. but didn't really check the reason for that. Will > take a time later to see what's happening. > > > > > > Both need some review and testing before being released. > > > > Any estimation when code is released? > > > > > Probably not before the next open window, but definitely before it is > > > released. > > Thanks for info. > > > > -- > bmeneg > PGP Key: http://bmeneg.com/pubkey.txt
On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote: > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote: > > Hi Mimi, > > ... > > > > > With just this change, the ima_tpm.sh test is failing. I assume it is > > > > > failing because it is reading the SHA1 TPM bank, not the SHA256 bank > > > > > to calculate the boot_aggregate hash. > > > > First question: is it correct to take sha256? Because on my test below it's > > > > reading sha1, because that's the content of /sys/kernel/security/ima/ascii_runtime_measurements > > > > > > I thought just kernel commit: 6f1a1d103b48 ima: ("Switch to ima_hash_algo for > > > > boot aggregate") from current linux-integrity tree is needed, but I tested it on > > > > b59fda449cf0 ("ima: Set again build_ima_appraise variable") (i.e. having all > > > > Robeto's ima patches, missing just last 2 commits from next-integrity head). > > > > What is needed to get your setup? > > > > > This isn't a configuration problem, but an issue of reading PCRs and > > > calculating the TPM bank appropriate boot_aggregate. If you're > > > calculating a sha256 boot_aggregate, then the test needs to read and > > > calculate the boot_aggregate by reading the SHA256 TPM bank. > > OK, I tested it on TPM 1.2 (no TPM 2.0 available atm). > > I guess you have TPM 2.0, that's why I didn't spot this issue. > > > > To sum that: my patch is required for any system without physical TPM with with > > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel > > version), because TPM 1.2 supports sha1 only boot aggregate. > > > > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with > > this patch, but also on current version in master, right? As you have > > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway. > > So this patch would help at least testing on VM without vTPM. > > > > If we consider to delay this change until we have the ima-evm-utils > released with the ima_boot_aggregate + make this test dependent on > both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in > case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could > have the test fixed for TPM1.2 && no-TPM cases until we get the full > support for multiple banks? As long as we're dealing with the "boot_aggregate", Maurizio just posted a kernel patch for including PCR 8 & 9 in the boot_aggregate. The existing IMA LTP "boot_aggregate" test is going to need to support this change. I'd appreciate if someone could send me a TPM event log, the PCRs, and the associated IMA ascii_runtime_measurements "boot_aggregate" from a system with a discrete TPM 2.0 with PCRs 8 & 9 events. > > > ... > > > > > The ima-evm-utils next-testing branch has code to calculate the > > > > > boot_aggregate based on multiple banks. > > > > I see, 696bf0b ("ima-evm-utils: calculate the digests for multiple TPM banks") > > > > I wonder whether it's reasonable trying to port that to ima_boot_aggregate.c or > > > > just depend on evmctl. External dependencies are sometimes complicated, but for > > > > IMA I incline to just require evmctl. > > > > > Unlike TPM 1.2, the TPM 2.0 device driver doesn't export the TPM PCRs. > > > Not only would you have a dependency on ima-evm-utils, but also on a > > > userspace application(s) for reading the TPM PCRs. That dependency > > > exists whether you're using evmctl to calculate the boot_aggregate or > > > doing it yourself. > > Hm, things get complicated. > > Yep I remember your patch to skip verifying TPM 2.0 PCR values > > https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/ > > At least thanks to Jerry Snitselaar since v5.6 we have > > /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also > > /sys/class/tpm/tpm0/device/description for older kernels). > > > > BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2, > > not sure if it indicate TPM 1.2, but I wouldn't rely on that. > > > > IIUC 'tpm_version_major' should be the only safe reference of the actual > TCG spec version being implemented by the hw TPM, in a sysfs standard > output. That was only upstreamed in linux-v5.6. Has it been backported? The PCRs are not exported for TPM 2.0, unfortunately, making regression tests dependent on a userspace app. The existing LTP ima_tpm.sh test looks for the PCRs in either /sys/class/tpm/tpm0/device/pcrs or /sys/class/misc/tpm0/device/pcrs. Perhaps piggyback on the pseudo PCR file to test for TPM 1.2. > > > ... > > > > > There's also a new test to verify the boot_aggregate. > > > > > > > $ VERBOSE=1 make check TESTS=boog_aggregate.test > > > > BTW I got some errors > > > > ... > > > > make check-TESTS > > > > make[2]: Entering directory '/home/foo/ima-evm-utils/tests' > > > > make[3]: Entering directory '/home/foo/ima-evm-utils/tests' > > > > make[4]: Entering directory '/home/foo/ima-evm-utils/tests' > > > > make[4]: Nothing to be done for 'boog_aggregate.log'. > > > > make[4]: Leaving directory '/home/foo/ima-evm-utils/tests' > > > > fatal: making test-suite.log: failed to create boog_aggregate.trs > > > > fatal: making test-suite.log: failed to create boog_aggregate.log > > > > make[3]: *** [Makefile:516: test-suite.log] Error 1 > > > > make[3]: Leaving directory '/home/foo/ima-evm-utils/tests' > > > > make[2]: *** [Makefile:625: check-TESTS] Error 2 > > > > make[2]: Leaving directory '/home/foo/ima-evm-utils/tests' > > > > make[1]: *** [Makefile:692: check-am] Error 2 > > > > make[1]: Leaving directory '/home/foo/ima-evm-utils/tests' > > > > make: *** [Makefile:514: check-recursive] Error 1 > > > > > [Cc'ing Vitaly] > > > > > The boot_aggregate.trs and boot_aggregate.log files are being created > > > in the tests/ directory. Is that directory read-only? > > Yes, drwxr-xr-x. Testing on fresh clone and issue persists. > > > > Yes, same thing here.. but didn't really check the reason for that. Will > take a time later to see what's happening. Thanks, much appreciated. I'm not seeing that here. Mimi
On Mon, 2020-06-15 at 17:01 -0300, Bruno Meneguele wrote: > On Mon, Jun 15, 2020 at 04:41:34PM -0300, Bruno Meneguele wrote: > > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote: > > > > The boot_aggregate.trs and boot_aggregate.log files are being created > > > > in the tests/ directory. Is that directory read-only? > > > Yes, drwxr-xr-x. Testing on fresh clone and issue persists. > > > > > > > Yes, same thing here.. but didn't really check the reason for that. Will > > take a time later to see what's happening. Cloning as root will cause that to happen. $ sudo git clone git://git.code.sf.net/p/linux-ima/ima-evm-utils --branch next-testing Cloning into 'ima-evm-utils'... remote: Enumerating objects: 1154, done. remote: Counting objects: 100% (1154/1154), done. remote: Compressing objects: 100% (1052/1052), done. remote: Total 1154 (delta 736), reused 182 (delta 96) Receiving objects: 100% (1154/1154), 335.12 KiB | 0 bytes/s, done. Resolving deltas: 100% (736/736), done. Checking connectivity... done. $ ls -lat ima-evm-utils/ | grep tests drwxr-xr-x. 2 root root 220 Jun 16 18:28 tests Mimi
On Mon Jun 15 20, Mimi Zohar wrote: >On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote: >> On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote: >> > Hi Mimi, >> > ... >> > > > > With just this change, the ima_tpm.sh test is failing. I assume it is >> > > > > failing because it is reading the SHA1 TPM bank, not the SHA256 bank >> > > > > to calculate the boot_aggregate hash. >> > > > First question: is it correct to take sha256? Because on my test below it's >> > > > reading sha1, because that's the content of /sys/kernel/security/ima/ascii_runtime_measurements >> > >> > > > I thought just kernel commit: 6f1a1d103b48 ima: ("Switch to ima_hash_algo for >> > > > boot aggregate") from current linux-integrity tree is needed, but I tested it on >> > > > b59fda449cf0 ("ima: Set again build_ima_appraise variable") (i.e. having all >> > > > Robeto's ima patches, missing just last 2 commits from next-integrity head). >> > > > What is needed to get your setup? >> > >> > > This isn't a configuration problem, but an issue of reading PCRs and >> > > calculating the TPM bank appropriate boot_aggregate. If you're >> > > calculating a sha256 boot_aggregate, then the test needs to read and >> > > calculate the boot_aggregate by reading the SHA256 TPM bank. >> > OK, I tested it on TPM 1.2 (no TPM 2.0 available atm). >> > I guess you have TPM 2.0, that's why I didn't spot this issue. >> > >> > To sum that: my patch is required for any system without physical TPM with with >> > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel >> > version), because TPM 1.2 supports sha1 only boot aggregate. >> > >> > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with >> > this patch, but also on current version in master, right? As you have >> > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway. >> > So this patch would help at least testing on VM without vTPM. >> > >> >> If we consider to delay this change until we have the ima-evm-utils >> released with the ima_boot_aggregate + make this test dependent on >> both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in >> case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could >> have the test fixed for TPM1.2 && no-TPM cases until we get the full >> support for multiple banks? > >As long as we're dealing with the "boot_aggregate", Maurizio just >posted a kernel patch for including PCR 8 & 9 in the boot_aggregate. > The existing IMA LTP "boot_aggregate" test is going to need to >support this change. > >I'd appreciate if someone could send me a TPM event log, the PCRs, and >the associated IMA ascii_runtime_measurements "boot_aggregate" from a >system with a discrete TPM 2.0 with PCRs 8 & 9 events. > >> >> > ... >> > > > > The ima-evm-utils next-testing branch has code to calculate the >> > > > > boot_aggregate based on multiple banks. >> > > > I see, 696bf0b ("ima-evm-utils: calculate the digests for multiple TPM banks") >> > > > I wonder whether it's reasonable trying to port that to ima_boot_aggregate.c or >> > > > just depend on evmctl. External dependencies are sometimes complicated, but for >> > > > IMA I incline to just require evmctl. >> > >> > > Unlike TPM 1.2, the TPM 2.0 device driver doesn't export the TPM PCRs. >> > > Not only would you have a dependency on ima-evm-utils, but also on a >> > > userspace application(s) for reading the TPM PCRs. That dependency >> > > exists whether you're using evmctl to calculate the boot_aggregate or >> > > doing it yourself. >> > Hm, things get complicated. >> > Yep I remember your patch to skip verifying TPM 2.0 PCR values >> > https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/ >> > At least thanks to Jerry Snitselaar since v5.6 we have >> > /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also >> > /sys/class/tpm/tpm0/device/description for older kernels). >> > >> > BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2, >> > not sure if it indicate TPM 1.2, but I wouldn't rely on that. >> > >> >> IIUC 'tpm_version_major' should be the only safe reference of the actual >> TCG spec version being implemented by the hw TPM, in a sysfs standard >> output. > >That was only upstreamed in linux-v5.6. Has it been backported? > Not that I know of. Since it isn't using chip->ops and only looks at chip->flags it could probably be backported, but I'd have to take a look at it. >The PCRs are not exported for TPM 2.0, unfortunately, making >regression tests dependent on a userspace app. The existing LTP >ima_tpm.sh test looks for the PCRs in either >/sys/class/tpm/tpm0/device/pcrs or /sys/class/misc/tpm0/device/pcrs. > Perhaps piggyback on the pseudo PCR file to test for TPM 1.2. > >> >> > ... >> > > > > There's also a new test to verify the boot_aggregate. >> > >> > > > > $ VERBOSE=1 make check TESTS=boog_aggregate.test >> > > > BTW I got some errors >> > > > ... >> > > > make check-TESTS >> > > > make[2]: Entering directory '/home/foo/ima-evm-utils/tests' >> > > > make[3]: Entering directory '/home/foo/ima-evm-utils/tests' >> > > > make[4]: Entering directory '/home/foo/ima-evm-utils/tests' >> > > > make[4]: Nothing to be done for 'boog_aggregate.log'. >> > > > make[4]: Leaving directory '/home/foo/ima-evm-utils/tests' >> > > > fatal: making test-suite.log: failed to create boog_aggregate.trs >> > > > fatal: making test-suite.log: failed to create boog_aggregate.log >> > > > make[3]: *** [Makefile:516: test-suite.log] Error 1 >> > > > make[3]: Leaving directory '/home/foo/ima-evm-utils/tests' >> > > > make[2]: *** [Makefile:625: check-TESTS] Error 2 >> > > > make[2]: Leaving directory '/home/foo/ima-evm-utils/tests' >> > > > make[1]: *** [Makefile:692: check-am] Error 2 >> > > > make[1]: Leaving directory '/home/foo/ima-evm-utils/tests' >> > > > make: *** [Makefile:514: check-recursive] Error 1 >> > >> > > [Cc'ing Vitaly] >> > >> > > The boot_aggregate.trs and boot_aggregate.log files are being created >> > > in the tests/ directory. Is that directory read-only? >> > Yes, drwxr-xr-x. Testing on fresh clone and issue persists. >> > >> >> Yes, same thing here.. but didn't really check the reason for that. Will >> take a time later to see what's happening. > >Thanks, much appreciated. I'm not seeing that here. > >Mimi >
On Tue, Jun 16, 2020 at 06:40:11PM -0400, Mimi Zohar wrote: > On Mon, 2020-06-15 at 17:01 -0300, Bruno Meneguele wrote: > > On Mon, Jun 15, 2020 at 04:41:34PM -0300, Bruno Meneguele wrote: > > > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote: > > > > > > The boot_aggregate.trs and boot_aggregate.log files are being created > > > > > in the tests/ directory. Is that directory read-only? > > > > Yes, drwxr-xr-x. Testing on fresh clone and issue persists. > > > > > > > > > > Yes, same thing here.. but didn't really check the reason for that. Will > > > take a time later to see what's happening. > > Cloning as root will cause that to happen. > > $ sudo git clone git://git.code.sf.net/p/linux-ima/ima-evm-utils --branch next-testing > Cloning into 'ima-evm-utils'... > remote: Enumerating objects: 1154, done. > remote: Counting objects: 100% (1154/1154), done. > remote: Compressing objects: 100% (1052/1052), done. > remote: Total 1154 (delta 736), reused 182 (delta 96) > Receiving objects: 100% (1154/1154), 335.12 KiB | 0 bytes/s, done. > Resolving deltas: 100% (736/736), done. > Checking connectivity... done. > > $ ls -lat ima-evm-utils/ | grep tests > drwxr-xr-x. 2 root root 220 Jun 16 18:28 tests > > Mimi > Yes, indeed. But what really happened with both I and Petr was trying to run the test copying and pasting what you've sent: $ VERBOSE=1 make check TESTS=boog_aggregate.test the typo in "boog" (vs "boot") was the cause. So I think we can ignore this issue here :).
On Tue, Jun 16, 2020 at 06:21:48PM -0700, Jerry Snitselaar wrote: > On Mon Jun 15 20, Mimi Zohar wrote: > > On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote: > > > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote: > > > > Hi Mimi, > > > > ... > > > > > > > With just this change, the ima_tpm.sh test is failing. I assume it is > > > > > > > failing because it is reading the SHA1 TPM bank, not the SHA256 bank > > > > > > > to calculate the boot_aggregate hash. > > > > > > First question: is it correct to take sha256? Because on my test below it's > > > > > > reading sha1, because that's the content of /sys/kernel/security/ima/ascii_runtime_measurements > > > > > > > > > > I thought just kernel commit: 6f1a1d103b48 ima: ("Switch to ima_hash_algo for > > > > > > boot aggregate") from current linux-integrity tree is needed, but I tested it on > > > > > > b59fda449cf0 ("ima: Set again build_ima_appraise variable") (i.e. having all > > > > > > Robeto's ima patches, missing just last 2 commits from next-integrity head). > > > > > > What is needed to get your setup? > > > > > > > > > This isn't a configuration problem, but an issue of reading PCRs and > > > > > calculating the TPM bank appropriate boot_aggregate. If you're > > > > > calculating a sha256 boot_aggregate, then the test needs to read and > > > > > calculate the boot_aggregate by reading the SHA256 TPM bank. > > > > OK, I tested it on TPM 1.2 (no TPM 2.0 available atm). > > > > I guess you have TPM 2.0, that's why I didn't spot this issue. > > > > > > > > To sum that: my patch is required for any system without physical TPM with with > > > > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel > > > > version), because TPM 1.2 supports sha1 only boot aggregate. > > > > > > > > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with > > > > this patch, but also on current version in master, right? As you have > > > > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway. > > > > So this patch would help at least testing on VM without vTPM. > > > > > > > > > > If we consider to delay this change until we have the ima-evm-utils > > > released with the ima_boot_aggregate + make this test dependent on > > > both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in > > > case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could > > > have the test fixed for TPM1.2 && no-TPM cases until we get the full > > > support for multiple banks? > > > > As long as we're dealing with the "boot_aggregate", Maurizio just > > posted a kernel patch for including PCR 8 & 9 in the boot_aggregate. > > The existing IMA LTP "boot_aggregate" test is going to need to > > support this change. > > > > I'd appreciate if someone could send me a TPM event log, the PCRs, and > > the associated IMA ascii_runtime_measurements "boot_aggregate" from a > > system with a discrete TPM 2.0 with PCRs 8 & 9 events. > > Maybe Maurizio already have it at hand? I can try to setup a system with grub2+tpm to get the log with pcr 8 and 9 filled. > > > > > > > ... > > > > > > > The ima-evm-utils next-testing branch has code to calculate the > > > > > > > boot_aggregate based on multiple banks. > > > > > > I see, 696bf0b ("ima-evm-utils: calculate the digests for multiple TPM banks") > > > > > > I wonder whether it's reasonable trying to port that to ima_boot_aggregate.c or > > > > > > just depend on evmctl. External dependencies are sometimes complicated, but for > > > > > > IMA I incline to just require evmctl. > > > > > > > > > Unlike TPM 1.2, the TPM 2.0 device driver doesn't export the TPM PCRs. > > > > > Not only would you have a dependency on ima-evm-utils, but also on a > > > > > userspace application(s) for reading the TPM PCRs. That dependency > > > > > exists whether you're using evmctl to calculate the boot_aggregate or > > > > > doing it yourself. > > > > Hm, things get complicated. > > > > Yep I remember your patch to skip verifying TPM 2.0 PCR values > > > > https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/ > > > > At least thanks to Jerry Snitselaar since v5.6 we have > > > > /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also > > > > /sys/class/tpm/tpm0/device/description for older kernels). > > > > > > > > BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2, > > > > not sure if it indicate TPM 1.2, but I wouldn't rely on that. > > > > Missed this last paragraph.. but /sys/class/tpm/tpm0/ppi/version has relation to the Physical Presence Interface version, which is the communication interface between firmware and OS afaik, and doesn't points to the TPM version: TPM2.0 may have PPI version 1.2 or 1.3. > > > > > > IIUC 'tpm_version_major' should be the only safe reference of the actual > > > TCG spec version being implemented by the hw TPM, in a sysfs standard > > > output. > > > > That was only upstreamed in linux-v5.6. Has it been backported? > > Hmm, well pointed. > > Not that I know of. Since it isn't using chip->ops and only > looks at chip->flags it could probably be backported, but I'd > have to take a look at it. > > > The PCRs are not exported for TPM 2.0, unfortunately, making > > regression tests dependent on a userspace app. The existing LTP > > ima_tpm.sh test looks for the PCRs in either > > /sys/class/tpm/tpm0/device/pcrs or /sys/class/misc/tpm0/device/pcrs. > > Perhaps piggyback on the pseudo PCR file to test for TPM 1.2. > > > > > > > > > ... > > > > > > > There's also a new test to verify the boot_aggregate. > > > > > > > > > > > $ VERBOSE=1 make check TESTS=boog_aggregate.test > > > > > > BTW I got some errors > > > > > > ... > > > > > > make check-TESTS > > > > > > make[2]: Entering directory '/home/foo/ima-evm-utils/tests' > > > > > > make[3]: Entering directory '/home/foo/ima-evm-utils/tests' > > > > > > make[4]: Entering directory '/home/foo/ima-evm-utils/tests' > > > > > > make[4]: Nothing to be done for 'boog_aggregate.log'. > > > > > > make[4]: Leaving directory '/home/foo/ima-evm-utils/tests' > > > > > > fatal: making test-suite.log: failed to create boog_aggregate.trs > > > > > > fatal: making test-suite.log: failed to create boog_aggregate.log > > > > > > make[3]: *** [Makefile:516: test-suite.log] Error 1 > > > > > > make[3]: Leaving directory '/home/foo/ima-evm-utils/tests' > > > > > > make[2]: *** [Makefile:625: check-TESTS] Error 2 > > > > > > make[2]: Leaving directory '/home/foo/ima-evm-utils/tests' > > > > > > make[1]: *** [Makefile:692: check-am] Error 2 > > > > > > make[1]: Leaving directory '/home/foo/ima-evm-utils/tests' > > > > > > make: *** [Makefile:514: check-recursive] Error 1 > > > > > > > > > [Cc'ing Vitaly] > > > > > > > > > The boot_aggregate.trs and boot_aggregate.log files are being created > > > > > in the tests/ directory. Is that directory read-only? > > > > Yes, drwxr-xr-x. Testing on fresh clone and issue persists. > > > > > > > > > > Yes, same thing here.. but didn't really check the reason for that. Will > > > take a time later to see what's happening. > > > > Thanks, much appreciated. I'm not seeing that here. > > > > Mimi > > >
On 6/17/2020 4:45 PM, Bruno Meneguele wrote: > On Tue, Jun 16, 2020 at 06:21:48PM -0700, Jerry Snitselaar wrote: >> On Mon Jun 15 20, Mimi Zohar wrote: >>> On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote: >>>> On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote: >>>>> Hi Mimi, >>>>> ... >>>>>>>> With just this change, the ima_tpm.sh test is failing. I assume it is >>>>>>>> failing because it is reading the SHA1 TPM bank, not the SHA256 bank >>>>>>>> to calculate the boot_aggregate hash. >>>>>>> First question: is it correct to take sha256? Because on my test below it's >>>>>>> reading sha1, because that's the content of /sys/kernel/security/ima/ascii_runtime_measurements >>>>>>> I thought just kernel commit: 6f1a1d103b48 ima: ("Switch to ima_hash_algo for >>>>>>> boot aggregate") from current linux-integrity tree is needed, but I tested it on >>>>>>> b59fda449cf0 ("ima: Set again build_ima_appraise variable") (i.e. having all >>>>>>> Robeto's ima patches, missing just last 2 commits from next-integrity head). >>>>>>> What is needed to get your setup? >>>>>> This isn't a configuration problem, but an issue of reading PCRs and >>>>>> calculating the TPM bank appropriate boot_aggregate. If you're >>>>>> calculating a sha256 boot_aggregate, then the test needs to read and >>>>>> calculate the boot_aggregate by reading the SHA256 TPM bank. >>>>> OK, I tested it on TPM 1.2 (no TPM 2.0 available atm). >>>>> I guess you have TPM 2.0, that's why I didn't spot this issue. >>>>> >>>>> To sum that: my patch is required for any system without physical TPM with with >>>>> kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel >>>>> version), because TPM 1.2 supports sha1 only boot aggregate. >>>>> >>>>> But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with >>>>> this patch, but also on current version in master, right? As you have >>>>> sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway. >>>>> So this patch would help at least testing on VM without vTPM. >>>>> >>>> If we consider to delay this change until we have the ima-evm-utils >>>> released with the ima_boot_aggregate + make this test dependent on >>>> both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in >>>> case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could >>>> have the test fixed for TPM1.2 && no-TPM cases until we get the full >>>> support for multiple banks? >>> As long as we're dealing with the "boot_aggregate", Maurizio just >>> posted a kernel patch for including PCR 8 & 9 in the boot_aggregate. >>> The existing IMA LTP "boot_aggregate" test is going to need to >>> support this change. >>> >>> I'd appreciate if someone could send me a TPM event log, the PCRs, and >>> the associated IMA ascii_runtime_measurements "boot_aggregate" from a >>> system with a discrete TPM 2.0 with PCRs 8 & 9 events. >>> > Maybe Maurizio already have it at hand? > I can try to setup a system with grub2+tpm to get the log with pcr 8 and > 9 filled. Hi Bruno, I confirm I have a couple of systems on where 8 & 9 and the IMA list are filled at boot (already shared with Mimi), now I am figuring out how to produce TPM event logs as well.
Hi Bruno, > > > > > > $ VERBOSE=1 make check TESTS=boog_aggregate.test > ^^^^ > boot > That's the issue :). Thanks! Obviously everything is working with correct test name :). Kind regards, Petr
Hi all, ... > > > I'd appreciate if someone could send me a TPM event log, the PCRs, and > > > the associated IMA ascii_runtime_measurements "boot_aggregate" from a > > > system with a discrete TPM 2.0 with PCRs 8 & 9 events. > Maybe Maurizio already have it at hand? I'd appreciate to have these files as well. > I can try to setup a system with grub2+tpm to get the log with pcr 8 and > 9 filled. > > > > > ... > > > > > > > > The ima-evm-utils next-testing branch has code to calculate the > > > > > > > > boot_aggregate based on multiple banks. > > > > > > > I see, 696bf0b ("ima-evm-utils: calculate the digests for multiple TPM banks") > > > > > > > I wonder whether it's reasonable trying to port that to ima_boot_aggregate.c or > > > > > > > just depend on evmctl. External dependencies are sometimes complicated, but for > > > > > > > IMA I incline to just require evmctl. > > > > > > Unlike TPM 1.2, the TPM 2.0 device driver doesn't export the TPM PCRs. > > > > > > Not only would you have a dependency on ima-evm-utils, but also on a > > > > > > userspace application(s) for reading the TPM PCRs. That dependency > > > > > > exists whether you're using evmctl to calculate the boot_aggregate or > > > > > > doing it yourself. > > > > > Hm, things get complicated. > > > > > Yep I remember your patch to skip verifying TPM 2.0 PCR values > > > > > https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/ > > > > > At least thanks to Jerry Snitselaar since v5.6 we have > > > > > /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also > > > > > /sys/class/tpm/tpm0/device/description for older kernels). > > > > > BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2, > > > > > not sure if it indicate TPM 1.2, but I wouldn't rely on that. > Missed this last paragraph.. but /sys/class/tpm/tpm0/ppi/version has > relation to the Physical Presence Interface version, which is the > communication interface between firmware and OS afaik, and doesn't > points to the TPM version: TPM2.0 may have PPI version 1.2 or 1.3. Kind regards, Petr
Hi all, > On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote: > > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote: > > > Hi Mimi, ... > > > To sum that: my patch is required for any system without physical TPM with with > > > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel > > > version), because TPM 1.2 supports sha1 only boot aggregate. > > > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with > > > this patch, but also on current version in master, right? As you have > > > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway. > > > So this patch would help at least testing on VM without vTPM. > > If we consider to delay this change until we have the ima-evm-utils > > released with the ima_boot_aggregate + make this test dependent on > > both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in > > case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could > > have the test fixed for TPM1.2 && no-TPM cases until we get the full > > support for multiple banks? +1 > As long as we're dealing with the "boot_aggregate", Maurizio just > posted a kernel patch for including PCR 8 & 9 in the boot_aggregate. > The existing IMA LTP "boot_aggregate" test is going to need to > support this change. I'm not sure if I did something wrong, but it looks to me that 'evmctl ima_boot_aggregate' does not provide backward compatibility with TPM 1.2. Or am I wrong? And given the fact that new evmctl is not released, I'd adapt the test just for TPM 1.2 && no-TPM as Bruno suggested (TCONF if /sys/class/tpm/tpm0/tpm_version_major presented and not 1, print info about TPM 2.0 not yet supported otherwise). BTW what is the correct way for systems with more TPM (is there any? It looks it's possible [1]). Which of them is used? Should I loop over /sys/class/tpm/tpm*/tpm_version_major or just use /sys/class/tpm/tpm0/tpm_version_major? Kind regards, Petr [1] https://letstrust.de/archives/29-New-fun-fact!.html
On Fri, 2020-06-19 at 10:21 +0200, Petr Vorel wrote: > Hi all, > > ... > > > > I'd appreciate if someone could send me a TPM event log, the PCRs, and > > > > the associated IMA ascii_runtime_measurements "boot_aggregate" from a > > > > system with a discrete TPM 2.0 with PCRs 8 & 9 events. > > > > Maybe Maurizio already have it at hand? > I'd appreciate to have these files as well. > > > I can try to setup a system with grub2+tpm to get the log with pcr 8 and > > 9 filled. Both RHEL 8 and Ubuntu 20.04 LTS have PCRs 8 & 9. I'll include one as another example for the tests/boot_aggregate.test. Mimi
Hi Mimi, > > ... > > > > > I'd appreciate if someone could send me a TPM event log, the PCRs, and > > > > > the associated IMA ascii_runtime_measurements "boot_aggregate" from a > > > > > system with a discrete TPM 2.0 with PCRs 8 & 9 events. > > > Maybe Maurizio already have it at hand? > > I'd appreciate to have these files as well. > > > I can try to setup a system with grub2+tpm to get the log with pcr 8 and > > > 9 filled. > Both RHEL 8 and Ubuntu 20.04 LTS have PCRs 8 & 9. I'll include one as > another example for the tests/boot_aggregate.test. Thank you! Kind regards, Petr
On Fri, 2020-06-19 at 12:07 +0200, Petr Vorel wrote: > Hi all, > > > On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote: > > > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote: > > > > Hi Mimi, > ... > > > > To sum that: my patch is required for any system without physical TPM with with > > > > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel > > > > version), because TPM 1.2 supports sha1 only boot aggregate. > > > > > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with > > > > this patch, but also on current version in master, right? As you have > > > > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway. > > > > So this patch would help at least testing on VM without vTPM. > > > > > If we consider to delay this change until we have the ima-evm-utils > > > released with the ima_boot_aggregate + make this test dependent on > > > both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in > > > case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could > > > have the test fixed for TPM1.2 && no-TPM cases until we get the full > > > support for multiple banks? > +1 > > > As long as we're dealing with the "boot_aggregate", Maurizio just > > posted a kernel patch for including PCR 8 & 9 in the boot_aggregate. > > The existing IMA LTP "boot_aggregate" test is going to need to > > support this change. > I'm not sure if I did something wrong, but it looks to me that 'evmctl > ima_boot_aggregate' does not provide backward compatibility with TPM 1.2. > Or am I wrong? Calculating the "boot_aggregate" - "evmctl ima_boot_aggregate" - for TPM 1.2 should work. Reading the code, it looks like it assumes that the crypto library supports SHA1 and SHA256. That assumption needs to be addressed. The tests/boot_aggregate.test logs are TPM 2.0. The test is failing on systems with a TPM 1.2. I'm working on a fix for this. Mimi
diff --git a/testcases/kernel/security/integrity/ima/tests/ima_measurements.sh b/testcases/kernel/security/integrity/ima/tests/ima_measurements.sh index 54237d688..50de4df98 100755 --- a/testcases/kernel/security/integrity/ima/tests/ima_measurements.sh +++ b/testcases/kernel/security/integrity/ima/tests/ima_measurements.sh @@ -6,7 +6,7 @@ # # Verify that measurements are added to the measurement list based on policy. -TST_NEEDS_CMDS="awk cut" +TST_NEEDS_CMDS="awk cut sed" TST_SETUP="setup" TST_CNT=3 TST_NEEDS_DEVICE=1 @@ -20,30 +20,8 @@ setup() TEST_FILE="$PWD/test.txt" POLICY="$IMA_DIR/policy" [ -f "$POLICY" ] || tst_res TINFO "not using default policy" - DIGEST_INDEX= - - local template="$(tail -1 $ASCII_MEASUREMENTS | cut -d' ' -f 3)" - local i - - # parse digest index - # https://www.kernel.org/doc/html/latest/security/IMA-templates.html#use - case "$template" in - ima|ima-ng|ima-sig) DIGEST_INDEX=4 ;; - *) - # using ima_template_fmt kernel parameter - local IFS="|" - i=4 - for word in $template; do - if [ "$word" = 'd' -o "$word" = 'd-ng' ]; then - DIGEST_INDEX=$i - break - fi - i=$((i+1)) - done - esac - [ -z "$DIGEST_INDEX" ] && tst_brk TCONF \ - "Cannot find digest index (template: '$template')" + set_digest_index } # TODO: find support for rmd128 rmd256 rmd320 wp256 wp384 tgr128 tgr160 @@ -82,44 +60,18 @@ compute_digest() ima_check() { - local delimiter=':' - local algorithm digest expected_digest line + local algorithm digest expected_digest line tmp # need to read file to get updated $ASCII_MEASUREMENTS cat $TEST_FILE > /dev/null line="$(grep $TEST_FILE $ASCII_MEASUREMENTS | tail -1)" - if [ -z "$line" ]; then - tst_res TFAIL "cannot find measurement record for '$TEST_FILE'" - return - fi - tst_res TINFO "measurement record: '$line'" - - digest=$(echo "$line" | cut -d' ' -f $DIGEST_INDEX) - if [ -z "$digest" ]; then - tst_res TFAIL "cannot find digest (index: $DIGEST_INDEX)" - return - fi - if [ "${digest#*$delimiter}" != "$digest" ]; then - algorithm=$(echo "$digest" | cut -d $delimiter -f 1) - digest=$(echo "$digest" | cut -d $delimiter -f 2) + if tmp=$(get_algorithm_digest "$line"); then + algorithm=$(echo "$tmp" | cut -d'|' -f1) + digest=$(echo "$tmp" | cut -d'|' -f2) else - case "${#digest}" in - 32) algorithm="md5" ;; - 40) algorithm="sha1" ;; - *) - tst_res TFAIL "algorithm must be either md5 or sha1 (digest: '$digest')" - return ;; - esac - fi - if [ -z "$algorithm" ]; then - tst_res TFAIL "cannot find algorithm" - return - fi - if [ -z "$digest" ]; then - tst_res TFAIL "cannot find digest" - return + tst_res TBROK "failed to get algorithm/digest for '$TEST_FILE': $tmp" fi tst_res TINFO "computing digest for $algorithm algorithm" diff --git a/testcases/kernel/security/integrity/ima/tests/ima_setup.sh b/testcases/kernel/security/integrity/ima/tests/ima_setup.sh index 58a12eda3..104088e52 100644 --- a/testcases/kernel/security/integrity/ima/tests/ima_setup.sh +++ b/testcases/kernel/security/integrity/ima/tests/ima_setup.sh @@ -112,6 +112,75 @@ ima_cleanup() fi } +set_digest_index() +{ + DIGEST_INDEX= + + local template="$(tail -1 $ASCII_MEASUREMENTS | cut -d' ' -f 3)" + local i word + + # parse digest index + # https://www.kernel.org/doc/html/latest/security/IMA-templates.html#use + case "$template" in + ima|ima-ng|ima-sig) DIGEST_INDEX=4 ;; + *) + # using ima_template_fmt kernel parameter + local IFS="|" + i=4 + for word in $template; do + if [ "$word" = 'd' -o "$word" = 'd-ng' ]; then + DIGEST_INDEX=$i + break + fi + i=$((i+1)) + done + esac + + [ -z "$DIGEST_INDEX" ] && tst_brk TCONF \ + "Cannot find digest index (template: '$template')" +} + +get_algorithm_digest() +{ + local line="$1" + local delimiter=':' + local algorithm digest + + if [ -z "$line" ]; then + echo "measurement record not found" + return 1 + fi + + digest=$(echo "$line" | cut -d' ' -f $DIGEST_INDEX) + if [ -z "$digest" ]; then + echo "digest not found (index: $DIGEST_INDEX, line: '$line')" + return 1 + fi + + if [ "${digest#*$delimiter}" != "$digest" ]; then + algorithm=$(echo "$digest" | cut -d $delimiter -f 1) + digest=$(echo "$digest" | cut -d $delimiter -f 2) + else + case "${#digest}" in + 32) algorithm="md5" ;; + 40) algorithm="sha1" ;; + *) + echo "algorithm must be either md5 or sha1 (digest: '$digest')" + return 1 ;; + esac + fi + if [ -z "$algorithm" ]; then + echo "algorithm not found" + return 1 + fi + if [ -z "$digest" ]; then + echo "digest not found" + return 1 + fi + + echo "$algorithm|$digest" +} + # loop device is needed to use only for tmpfs TMPDIR="${TMPDIR:-/tmp}" if [ "$(df -T $TMPDIR | tail -1 | awk '{print $2}')" != "tmpfs" -a -n "$TST_NEEDS_DEVICE" ]; then diff --git a/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh b/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh index c69f891f1..444d76d62 100755 --- a/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh +++ b/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh @@ -7,6 +7,7 @@ # Verify the boot and PCR aggregates. TST_CNT=2 +TST_SETUP="set_digest_index" TST_NEEDS_CMDS="awk cut ima_boot_aggregate" . ima_setup.sh @@ -15,29 +16,39 @@ test1() { tst_res TINFO "verify boot aggregate" - local zero="0000000000000000000000000000000000000000" local tpm_bios="$SECURITYFS/tpm0/binary_bios_measurements" local ima_measurements="$ASCII_MEASUREMENTS" - local boot_aggregate boot_hash line + local algorithm boot_aggregate digest line tmp zero # IMA boot aggregate read line < $ima_measurements - boot_hash=$(echo $line | awk '{print $(NF-1)}' | cut -d':' -f2) + + if tmp=$(get_algorithm_digest "$line"); then + algorithm=$(echo "$tmp" | cut -d'|' -f1) + digest=$(echo "$tmp" | cut -d'|' -f2) + else + tst_res TBROK "failed to get algorithm/digest: $tmp" + fi + + tst_res TINFO "used algorithm: $algorithm" if [ ! -f "$tpm_bios" ]; then tst_res TINFO "TPM Hardware Support not enabled in kernel or no TPM chip found" - if [ "$boot_hash" = "$zero" ]; then - tst_res TPASS "bios boot aggregate is 0" + zero=$(echo $digest | awk '{gsub(/./, "0")}; {print}') + if [ "$digest" = "$zero" ]; then + tst_res TPASS "bios boot aggregate is $zero" else - tst_res TFAIL "bios boot aggregate is not 0" + tst_res TFAIL "bios boot aggregate is not $zero ($digest)" fi else boot_aggregate=$(ima_boot_aggregate $tpm_bios | grep "boot_aggregate:" | cut -d':' -f2) - if [ "$boot_hash" = "$boot_aggregate" ]; then - tst_res TPASS "bios aggregate matches IMA boot aggregate" + tst_res TINFO "IMA boot aggregate: '$boot_aggregate'" + + if [ "$digest" = "$boot_aggregate" ]; then + tst_res TPASS "bios boot aggregate matches IMA boot aggregate" else - tst_res TFAIL "bios aggregate does not match IMA boot aggregate" + tst_res TFAIL "bios boot aggregate does not match IMA boot aggregate ($digest)" fi fi }
Fixes test for kernel commit: 6f1a1d103b48 ima: ("Switch to ima_hash_algo for boot aggregate") from current linux-integrity tree. Tests was failing, because it expect SHA1 hash, but for TPM 2.0 is now used IMA default hash algorithm (by default default SHA256). This is similar for entries in IMA measurement list so we can reuse already existing code. Signed-off-by: Petr Vorel <pvorel@suse.cz> --- changes v1->v2: * removing global variables from get_algorithm_digest (hopefully it's less ugly) Tested only on VM. Can anybody test it on real HW? Kind regards, Petr .../integrity/ima/tests/ima_measurements.sh | 62 ++--------------- .../security/integrity/ima/tests/ima_setup.sh | 69 +++++++++++++++++++ .../security/integrity/ima/tests/ima_tpm.sh | 29 +++++--- 3 files changed, 96 insertions(+), 64 deletions(-)