Re: [Linux-ima-user] Initramfs and IMA Appraisal

[Dmitry K. <d.k...@sa...>]

On 02/12/14 17:42, Mimi Zohar wrote:
> On Fri, 2014-11-28 at 16:07 +0200, Dmitry Kasatkin wrote: 
>> On 27/11/14 11:15, Christophe Fillot wrote:
>>> On 11/26/2014 11:12 PM, Mimi Zohar wrote:
>>>
>>>> With commit "8feba3f Add support for signing a file hash", evmctl now
>>>> supports signing file hashes.  You might want to create a manifest file
>>>> containing all the files and their hashes, similar to the .deb md5sums
>>>> file, and then sign the files hashes.
>>>>
>>>> find <dir> -type f -exec sha256sum {} \;  >> ./sha256sums
>>>> cat ./sha256sums | evmctl sign_hash -a sha256 --key "${PRIVKEY}" > sha256sums.sig
>>> Thanks for the tip!
>>>
>>>>>       - At boot, before reading and enabling the IMA policy, the attributes
>>>>>         are loaded from the attribute file and applied to the TMPFS. Then,
>>>>>         when the policy is loaded, no appraisal error occurs.
>>>> Interesting that the EVM signatures are valid, as the HMAC calculation
>>>> includes the i_ino.  This means that the extracted files have the same
>>>> i_ino as the original version that you signed.  I'm not sure that we can
>>>> really count on that, nor am I sure how to resolve this problem.
>>> In fact I create and restore the EVM signatures, but I don't enable EVM 
>>> at the moment.
>>> I don't see an easy solution for that, if I understand correctly the 
>>> tmpfs code, it
>>> calls get_next_ino() to generate inode numbers, and they will probably 
>>> be random at
>>> each boot.
>>>
>>> Also, even if tar format (for xattr support) is used instead of cpio to 
>>> uncompress
>>> initramfs into tmpfs FS, we will still have this problem for EVM signatures.
> Agreed, the same EVM signature problem exists for any solution.  We have
> three options:
> - including a manifest file as you described
> - extending the CPIO format to include xattrs
> - adding initramfs tar support
>
> I've started looking at the 2nd option.
>
>>> Maybe a solution would be to ignore inode number for specific 
>>> filesystems during
>>> EVM signature calculation (and have an option in evmctl for that too) ?
> This sounds like the right direction.
>
>> I have patches I am working on  - Immutable EVM signatures, which will
>> not include i_no and iversion.
>> It should solve this problem.
> In the context of an initramfs, I'm not sure what "immutable" means.
> Does "immutable" imply that the file can not be removed?  The memory
> associated with the rootfs is cleaned up before switching root.  Is this
> a problem?

Immutable == Unreplaceable EVM signatures. Not converted to HMAC.
For permanently protecting file xattrs and attr...
Immutable is bad word here?

- Dmitry

>>>> Are you using an initrd not an initramfs?  According to
>>>> Documentation/filesystems/ramfs-rootfs-initramfs.txt, "If CONFIG_TMPFS
>>>> is enabled, rootfs will use tmpfs instead of ramfs by default".
>>>>
>>> Yes, that what I thought too, but it seems that it is not really the 
>>> case because
>>> of this test:
>>>
>>>      if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
>>>          (!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
>>>          err = shmem_init();
>>>          is_tmpfs = true;
>>>      } else {
>>>          err = init_ramfs_fs();
>>>      }
> Is "BLK_DEV_RAM" enabled?  Without it enabled, with BLK_DEV_INITRD
> enabled, I'm getting a builtin initramfs.  Look at init/initramfs.c:
> populate_rootfs().
>
> Mimi
>
>