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

[Mimi Z. <zo...@li...>]

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)?

Mimi