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

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

On Wed, 2014-12-03 at 15:08 +0200, Dmitry Kasatkin wrote: 
> 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?

For "security.ima" immutable implies not only that the extended
attribute does not change, but also that the file data can not change.

For EVM, immutable would imply not only that the "security.evm" extended
attribute, as you're suggesting, does not change, but would also prevent
any of the other file metadata from changing either.

At that point the file data and metadata are immutable.  The next step
would be making the file immutable, preventing it from being removed
and/or replaced.

What are the security implications of removing the i_ino (and iversion)
from the HMAC calculation?  What are the risks associated with it?

Mimi