Re: [Linux-ima-user] IMA overwrites xattr even if it has got correct signature

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

On Wed, 2016-02-24 at 15:23 +0200, Dmitry Rozhkov wrote:
> Hi!
> 
> I'm working on integrating IMA and swupd (Clear Linux software updates)
> and I'm experiencing problems with updating or installing new files on
> systems with IMA enabled.
>
> The problem comes from the fact that the IMA kernel module
> unconditionally overwrites the security.ima extended attribute upon
> closing a file:
> 1. the swupd client downloads a tarball with updates to /var/lib/swupd;
> 2. then unpacks the updated files preserving xattrs including
> security.ima with file signatures;
> 3. as soon as tar closes the unpacked files the kernel wipes out the
> content of security.ima and puts new value (files' hashes without
> signatures).
> 
> AFAIU this happens in the kernel hook ima_file_free() called as a final
> step of __dput() upon closing a file handle and freeing its structure.
> So there is no way to intervene and to prevent this xattr reset.
> 
> As result I can't use software updates together with an IMA policy
> where all executables must be signed.
> 
> Is it possible not to overwrite a file's security.ima if upon closing
> the file its security.ima contains a correct signed hash already? I saw
> Mimi mentioned the patch doing exactly that a month ago.

Commit c68ed80 "ima: limit file hash setting by user to fix and log
modes" prevents writing a file hash as the security.ima xattr, which is
a bit different than the use case that you described.  In that case,
userspace is attempting to write the xattr.

In your usecase scenario, ima_check_last_writer() calls
ima_update_xattr() to write the xattr.  It should prevent writing a
hash, when the IMA_DIGSIG flag is set.  

Some questions for debugging this.  setxattr sets the IMA_DIGSIG flag.
How is swupd writing out security.ima?   Why isn't IMA_DIGSIG being set?

Mimi