Re: RFC: Make it practical to ship EVM signatures

[Mimi Zohar <zohar@linux.vnet.ibm.com>]

On Mon, 2017-10-09 at 10:59 -0700, Matthew Garrett wrote:
> On Mon, Oct 9, 2017 at 10:51 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> >> >> I'm not really clear on what attacks are prevented by using the inode
> >> >> number. If I'm able to preserve all the other security metadata when
> >> >> copying a file, I can just create a hardlink to the original instead
> >> >> and have the same outcome.
> >> >
> >> > The issue is the ability of having different security metadata, not
> >> > the same security metadata. (I need to refresh my memory as to hard
> >> > links, and whether they can have different security metadata.)
> >>
> >> If the security metadata is different then copying another
> >> security.evm will fail, surely?
> >
> > The assumption here is that security.ima exists and is included in the
> > HMAC calculation.  For files which are not included in the IMA policy,
> > the only thing binding the file data and metadata is the i_ino and
> > uuid.
> 
> Ok, that makes sense. But for cases where we do have security.ima, the
> inode doesn't seem to provide additional security but does make
> deployment more difficult. Does supporting this use case seem
> reasonable?

Yes!