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

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

On 04/30/2014 07:10 PM, Mimi Zohar wrote:
> On Wed, 2014-04-30 at 10:34 +0300, Dmitry Kasatkin wrote:
>> Hello,
>>
>>
>> On 30 April 2014 09:43, Andreas Steffen <and...@st...> wrote:
>>> Hi Mimi,
>>>
>>> I'm currently updating strongSwan's remote attestation capability
>>> to include the new IMA-NG hash formats.
>
> Nice!
>
>> While inspecting the IMA
>>> source code I noticed that the hash of the template data computed
>>> by im_calc_field_array_hash_tfm() in ima_crypto.c depends on the
>>> endianness of the host platform:
>>>
>>>    rc = crypto_shash_update(&desc.shash,
>>>                (const u8 *) &field_data[i].len,
>>>                 sizeof(field_data[i].len));
>>>
>>> Since the attestation server reconstructs the template data hash
>>> from the SHA-1/SHA-256 file hash and absolute file name stored in
>>> the reference database I would be much happier if the 32 bit
>>> unsigned integer stored in field_data[i].len would be converted into
>>> platform-independent network order before these four bytes are
>>> included in the template hash. With the current code the attestation
>>> server must know the endianness of each of its clients in order to
>>> generate the correct hash value.
>>>
>
> Yes, I'm aware of this issue.
>
>> It is very good point. Measurement list should not depend on endianness.
>
> The measurement lists aren't network facing, but consumed by a userspace
> application/server.  The question is whether converting the securityfs
> binary/ascii measurement lists to network byte order is the
> responsibility of the kernel or should this be done by userspace
> application/server?
>
> CC'ing Roberto for his comments, as he's upstreamed OAT patches.
>

Hi Mimi, all

the TCG consortium defined a set of specifications so that
measurements can be arranged in a XML document. For IMA measurements
we found that the fields 'Type' and 'Image' of the object ValuesType
can be used to store respectively the template name and template data
in binary format (encoded in base 64).

This part of the specifications can be found at the URL:

http://www.trustedcomputinggroup.org/files/temp/643D2506-1D09-3519-ADA1A8A4C92A3A98/IWG%20SimpleObject_Schema_Specification_v1.pdf

at page 11.


 From what I understand, an userspace tool that handles the remote
attestation protocol should take raw data as is and store it directly
in the integrity report. The advantage to do that is that userspace
tools do not need the ability to understand raw data, that are
interpreted by an analysis tool after doing the unmarshalling of the
report.

So, I think that it is better to modify the IMA code to fix this issue.

Roberto


> thanks,
>
> Mimi
>
>>> Since the IMA-NG code has already been released with the 3.13 kernel
>>> I don't know if it is possible to include my proposed change.
>>> It would make life really much easier!
>>>
>>
>> It should be possible. I do not think it is so widely used "format"
>> now to allow it.
>> Other packages can be fixed...
>
>