[PATCH 5/6] ima: measure TPM update counter at ima_init

Mimi Zohar zohar at linux.ibm.com
Thu Aug 3 18:18:57 PDT 2023


On Thu, 2023-08-03 at 16:34 -0700, Tushar Sugandhi wrote:

> >> +++ b/security/integrity/ima/ima_init.c
> >> @@ -154,5 +154,8 @@ int __init ima_init(void)
> >>   				  UTS_RELEASE, strlen(UTS_RELEASE), false,
> >>   				  NULL, 0);
> >>   
> >> +	/* Measures TPM update counter at ima_init */
> >> +	ima_measure_update_counter("ima_init_tpm_update_counter");
> >> +
> > With "ima_policy=critical_data" on the boot command line, the IMA
> > measurement list record looks like:
> >
> > 6e190cc643ff0b718485966a0300473baedface735 ima_init_tpm_update_counter 7570646174655f636f756e7465723d3330383b
> >
> > Please change the "ima_init_tpm_update_counter" to something shorter
> > and the hex encoded ascii string and pcr counter to something readable.
> I believe you are seeing the above line in ascill_runtime_measurements log.

Yes, the ascii_runtime_measurements are suppose to be readable to the
end user.

> The ascii logging format is consistent with other event data for 
> critical_data event e.g. kernel_version.

Then you got it wrong.

> 10 8f449175bbf88bc55fc1127466628c39a3957d15 ima-buf 
> sha1:4acab4fbb08db663b7b7b4528e8729187d726782 kernel_version 
> 362e332e302d7263332b
> 10 f10678b63c4b2529339dff02282e63d9c6bb0385 ima-buf 
> sha1:d8c187524412f74a961f2051a9529c009e700337 
> ima_init_tpm_update_counter 7570646174655f636f756e7465723d3133303b
> 
> Entries in the binary runtime measurements look readable to me.

You've inverted the meaning of the ascii and binary runtime measurement
lists.  For comparison look at the ima-ng/ima-sig records.

> ima_init_tpm_update_counter update_counter=130;
> ...
> kexec_load_tpm_update_counte rupdate_counter=133;
> 
> Please let me know if you still want me to change the format.

OI course the ascii measurement list should be human readable.

> > Perhaps name this critical-data "tpm" and "tpm-info", similar to the
>  From patch 4/6:
> +    result = ima_measure_critical_data("tpm_pcr_update_counter", 
> event_name,
> +                  buf, buf_len, false, NULL, 0);
> 
> The critical_data event_label value is currently set to 
> "tpm_pcr_update_counter".

Why is the string so long?   Long strings or variables don't make the
code or logs more understandable.  Please shorten both the strings and
variables.

> I can rename event_label to "tpm-info", so that the admins can filter the
> event in IMA policy based on the label if needed.

The new record needs to be self containd and verifiable.  The
additional info I suggested were just examples.  Please take the time
to consider what needs to be included in the new record.  Decide
whether this is a TPM security critical data record.  Only then, decide
on the naming.

-- 
thanks,

Mimi





More information about the kexec mailing list