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

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

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?

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