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

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

On 04/30/2014 11:43 PM, Mimi Zohar wrote:
> On Wed, 2014-04-30 at 19:40 +0200, Roberto Sassu wrote:
>> 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.
>
> Ok.  Besides the field length, is there any other data which should be
> defined in a platform independent format (eg. template_data_len)?
>

Yes. I think also template fields representing integers (like the
inode UID/GID).

A not invasive solution to overcome this problem would be reporting
the endianness of the platform that created measurements in the first
measurement (boot_aggregate), whose format could be extended to
include a new field (other measurements would be still created with
the 'ima-ng' format). A parsing library (e.g. the ima_measure tool
of LTP) could use this information to interpret data and eventually
perform the conversion before returning data to callers.

Roberto


> Mimi
>
>
>