Re: [Linux-ima-user] Offline image creation: evm signing files problem with ubifs.

[Martin T. <mto...@gm...>]

Hi Mimi,


On Wed, Oct 11, 2017 at 6:21 PM, Mimi Zohar <zo...@li...> wrote:
> On Wed, 2017-10-11 at 13:45 +0100, Martin Townsend wrote:
>> Hi,
>>
>> I'm trying to take a ubifs image load it into nandsim sign all the
>> files and then recreate the ubifs image on a host PC and then flash
>> onto the real target.
>>
>> So far I can IMA sign all the files and recreate the ubifs image and
>> then flash the target and all is well.  The problem is with EVM; once
>> the image is loaded into nandsim and mounted to /mnt/ubi I sign with:
>>
>> evmctl sign --imasig  --generation 0 --uuid --smack --key
>> /mnt/ubi/path/to/private_key /mnt/ubi/path/to/file
>>
>> and then verify with
>>
>> evmctl verify --generation 0 --uuid --smack --key
>> /mnt/ubi/path/to/public_key /mnt/ubi/path/to/file
>>
>> And this is fine the hashes match.  Once I then recreate the ubifs
>> with mkfs.ubifs and then reload into the nand simulator the same
>> verify command fails with
>> Verification failed: 35
>> errno: No data available (61)
>>
>> I stepped through the code and I think it's because the hashes now do not match.
>>
>> After reading a few things about inodes in offline images I'm
>> wondering if I have to use the --ino option, if so what do I have to
>> pass to this argument and if someone could explain what the problem is
>> with inodes?
>
> We're working on making EVM signatures portable (and immutable).
>  Please look at the recent discussions on the new linux-integrity
> mailing list - https://www.spinics.net/lists/linux-integrity/.
>
> Mimi
>

Sounds very promising and is probably exactly what I require.  Sadly I
need something with the kernel we have which will be 4.9 by the time
we release.

I checked the inode with the stat command before recreating the image
with mkfs.ubifs in nand simulator and the inode on the real target and
they matched.  After recreating the image and reloading the new ubifs
the inode was different so mkfs.ubifs is re-assigning inode numbers
I'm guessing.  We are adding keys to the rootfs in the mounted image
before recreating the ubifs so maybe this is upsetting all the inode
numbers, I'm not really sure how they get assigned by mkfs.ubifs.

I see there is a patch:
https://sourceforge.net/p/linux-ima/mailman/message/3464
that uses user.image-inode-number extended attribute and requires
evmctl, mkfs.ubifs being called a few times. I will investigate this
further.

I will also look at how mkfs.ubifs works with regards to inode numbers
to see if anything can be done here.  If anyone has any ideas they
would be greatly appreciated.

Many Thanks,
Martin.