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

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

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.

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...