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

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

On Wed, 2014-12-03 at 17:14 +0200, Dmitry Kasatkin wrote: 
> On 03/12/14 16:00, Mimi Zohar wrote:
> > On Wed, 2014-12-03 at 15:08 +0200, Dmitry Kasatkin wrote: 

> > 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.
> 
> This is exactly what patchset is doing.
> > 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.
> 
> This is achieved by setting file immutable bit "chattr +i foo".
> Immutable bit needs to be protected.
> I posted patch about it
> 
> http://sourceforge.net/p/linux-ima/mailman/message/32893464/

[CC'ing Dave Safford]

Yes, using the immutable bit makes files, well, "immutable". :)  Being
able to piggy-back on the existing immutable bit would be nice, but
requiring software updates to first remove the immutable bit, before
being able to remove them, doesn't seem feasible.

We want the equivalent of the immutable bit, an immutable or "locked"
flag, which starts out as disabled and is enabled during boot.  Once
enabled, the flag cannot be disabled.  This would allow software
packages to be updated, prior to the "locked" flag being set.

> > What are the security implications of removing the i_ino (and iversion)
> > from the HMAC calculation?  What are the risks associated with it?
> 
> iversion has no any value in EVM protection as it can be arbitrary changed.
> 
> i_no is more tricky.
> It prevents pasting of inode from "other" filesystem which uses the
> "same" HMAC key.
> Between systems HMAC key is different...

> From other hand when using signatures, public key is the same.
> It looks like pasting of inodes from different filesystems are easy.

Or even the same filesystem.

> But we should not forget that file is immutable - data and attrs cannot
> be changed.
> Signer controls the key and what he signs.
> Substituting file with another file from the same signer does not seem
> to be a big issue...

Files, signed by trusted parties, are known to have vulnerabilities.

> But there may be a different solution for this.
> Leave security.evm with HMAC functioning as it is and add new extended
> attribute security.evmsig
> which will protect attrs and xattrs additionally with signatures.

Let's think about this some.

Mimi