Re: [Linux-ima-user] Endianness-dependent IMA field array hash

[Roberto S. <rob...@po...>]

On 05/02/2014 02:52 PM, Mimi Zohar wrote:
> On Thu, 2014-05-01 at 11:07 +0200, Andreas Steffen wrote:
>> Hello,
>>
>> just to make it clear. There is no problem with the length
>> fields in the raw binary measurement list
>>
>>    /sys/kernel/security/ima/binary_runtime_measurements
>>
>> being in host order since this list is handled by the local
>> Attestation Integrity Measurement Collector (IMC) which
>> has the same endianness as the underlying kernel. The
>> information which the Attestation IMC includes in the
>> integrity report (TCG TNC PTS Binding for the IF-M Protocol)
>> is the template hash of each measurement as it was extended into
>> PCR 10 (which with a current version 1.2 TPM is a 20 byte SHA-1 value).
>> Additional information included in the  integrity report is the
>> eventname (a modified absolute filename or boot_aggregate) and the hash
>> algorithm with which the file itself was hashed ("sha1:", "sha256",
>> etc.).
>>
>> My only request is to convert the field lengths into network
>> order when they are actually hashed into the final measurement value:
>>
>>    u32 field_data_len = htonl(field_data[i].len);
>>
>>    rc = crypto_shash_update(&desc.shash,
>>                (const u8 *) &field_data_len,
>>                 sizeof(field_data_len));
>>
>> With this simple change the endianness of the client platform doesn't
>> have to be included in the integrity report (which would be an awful
>> kludge anyway).
>>
>> A platform-independent template hash has also the big advantage that
>> the measurement values of [non-executable] configuration files would be
>> the same on all platforms.
>
> Ok. So for now, only the field length needs to be in a
> platform-independent byte order to calculate the template hash.
> However, the flexible template format permits us to define new fields,
> such as gid/uid, which are included in the hash calculation.  These new
> fields might also need to be converted to a platform-independent byte
> order for the hash calculation.
>
> Roberto, perhaps in the field definition, itself, we could include a bit
> indicating whether the field needs to be converted to a
> platform-independent byte order.
>

Hi Mimi

the conversion can be done directly by the helper that
field init() functions use for writing data in a buffer,
ima_write_template_field_data(). Since this function takes
the data format as input, for data types like uint32_t
it could perform the conversion before writing a buffer.

Roberto


> Andreas, did you want to post the patch?
>
> thanks,
>
> Mimi
>