[LTP] [RFC PATCH 0/2] IMA: Rewrite tests into new API + fixes

[Nayna Jain]

On 01/26/2018 11:21 PM, Petr Vorel wrote:
>
>> Until the IMA-measurement list supports TPM 2.0 hash agility, the
>> template name defines the old ("ima") vs. new formats.  The builtin
>> new template formats are "ima-ng" and "ima-sig", but custom formats
>> can be defined (eg. ima_template_fmt="d-ng|n-ng|sig") on the boot
>> command line.  "d-ng|n-ng|sig" is the definition for ima-sig.
> OK, we cannot rely on the default format. I'll fix it :-).
>
>>>> ima_boot_aggregate.c defines the BIOS MAX_EVENT_SIZE BIOS size as 500,
>>>> but I'm currently seeing BIOS events larger than 4k.
>>> So, what is the recommended size?
>>> Any reference to it?
>> According to Kenneth Goldman, the maximum BIOS event entry for TPM 1.2
>> is undefined.  For TPM 2.0 this was corrected.  The spec says, "For
>> software parsing the event log, the parser can choose an arbitrary
>> maximum size, but this specification recommends a maximum value for
>> the TCG_PCR_EVENT2.eventSize field of 1MB."
> Great, thanks for info. Just for a record links to the specification [1].
>
>> I think the BIOS event log is currently only exported via sysfs for
>> TPM 1.2.
> This commit 4d23cc323cdb ("tpm: add securityfs support for TPM 2.0 firmware event log")
> adds security [1]. And indeed structs tcg_pcr_event and tcg_pcr_event2 defined
> in [2] on pages 15 and 16 were added in this commit and used in TPM 2.0 related
> functions calc_tpm2_event_size(), tpm2_bios_measurements_start() and
> tpm2_bios_measurements_next().

Unlike TPM 1.2, TPM 2.0 support for firmware event log exports only 
binary_bios_measurements to securityfs. The binary file can be parsed to 
generate the ascii format.

The initial commit added support to retrieve the TPM 2.0 event log for 
device tree based platforms. Similar support for EFI is being upstreamed 
in this open window for Linux 4.16(https://lkml.org/lkml/2018/1/8/199)

Thanks & Regards,
     - Nayna


>
>>>> Since these tests were first written, Roberto's IMA templates and
>>>> Dmitry's support for larger digests were upstreamed.  With the new
>>>> template format, the file hash is prefixed with the hash algorithm.
>>>>   Before comparing the calculated boot aggregate with the value in the
>>>> IMA measurement list, the hash algorithm needs to be removed.
>>> Do you mean entries in /sys/kernel/security/ima/ascii_runtime_measurements ?
>>> system with config CONFIG_IMA_DEFAULT_HASH_SHA256=y
>>> 10 4814642f7955ad7a9c7b47785d002374b34902fd ima-ng sha256:f20cec9d158c4c453899f97595c40257c2518a40a310a550a1cd26a63e7fff7a /usr/lib64/libsha1detectcoll.so.1.0.0
>>> system with config CONFIG_IMA_DEFAULT_HASH_SHA1=y
>>> 10 2990cfe74ff309268e4fb928102574c28f9bb876 ima-ng sha1:71b543ad6af36b0976d0e3f71fed4ce0954eda0c /var/log/messages
>> Exactly.  The following code snippet strips off the hash algorithm,
>> before doing the hash comparison.  I'm sure there are better ways of
>> doing it.
>> +++ b/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh
>> @@ -39,7 +39,7 @@ test1()
>>          # IMA boot aggregate
>>          read line < $ima_measurements
>> -       ima_aggr=$(expr substr "${line}" 49 40)
>> +       ima_aggr=$(echo "$line" | cut -d' ' -f4 | cut -d':' -f2)
>
>>> As it's done with grep it shouldn't be needed:
>>> grep -q '^CONFIG_IMA_DEFAULT_HASH_SHA256=y' /boot/config-$(uname -r) && \
>>> 		HASH_COMMAND="sha256sum"
>>> I kept sha1sum as the default command for checking and I'm detecting with
>>> CONFIG_IMA_DEFAULT_HASH_SHA256 whether to use sha256:
>>> This is not enough, I'll add checks for CONFIG_IMA_DEFAULT_HASH_SHA512 and
>>> CONFIG_IMA_DEFAULT_HASH_WP512.
>> The list of supported hash algorithms is defined in
>> include/uapi/linux/hash_info.h.
> I see. And constants I take into account are values for ima template.
>
>> The first entry, the boot aggregate, is always sha1.  The rest of the
>> measurements will be the same hash algorithm, either as Kconfig
>> defined or as specified on the boot command line "ima_hash=" option,
>> per boot.
>> With the support for carrying the IMA-measurement list across kexec,
>> the measurement list might contain entries with different hash
>> algorithms.
> OK, I'll detect correct hash algorithm and check it.
>
>>>>   
>>>> For the new template format measurement lists, walking the measurement
>>>> list, re-calculating the PCRs and comparing them with the HW or vTPM
>>>> PCRs fail.  The ima-evm-utils package has a working version.  Invoke
>>>> "evmctl" with the "ima_measurement" option.
>>> So you mean that src/ima_measure.c is broken and should be replaced by evmctl from your
>>> repository on sf.net [4]? Fortunately this package is on all major distros [5] (except
>>> Debian, but Ubuntu package is installable on Debian), so we don't need to include your
>>> repository as submodule.
>> Fantastic!  So we'll concentrate on extending ima-evm-utils.
> There might be problem in old distros, where users will have to compile it themselves.
> It'd be more comfortable for users to have all the source codes in LTP tree, so if they
> report problems to us we might copy your source to LTP git or use it as submodule. But
> I'll try to avoid it.
>
>> thanks,
> Thanks a lot for your help!
>
>> Mimi
>
> Kind regards,
> Petr
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9&id=4d23cc323cdbee1cbcd8a7f059fff9ef2b0c473d
> [2] https://www.trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev9-150513_Public-Review.pdf
>