Re: RFC: Make it practical to ship EVM signatures

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

On Fri, 2017-09-29 at 13:09 -0700, Matthew Garrett wrote:
> On Fri, Sep 29, 2017 at 1:01 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Fri, 2017-09-29 at 12:17 -0700, Matthew Garrett wrote:
> >> I'm arguing that (for our case at least) the only way we can use IMA
> >> is to rely on using a digital signature - we can either have that
> >> digital signature be in security.ima, or we can have it in
> >> security.evm. Since we need that signature in any case, we derive no
> >> benefit from having security.evm be an hmac - our two reasonable
> >> choices are:
> >>
> >> 1) security.ima as a digital signature, security.evm as an hmac
> >> 2) security.ima as a hash, security.evm as a digital signature
> >
> > There's a major difference between security.ima containing a file hash
> > vs a signature.  A signature, assuming the file_check hook is in
> > policy, prevents the file from being modified, making the file
> > "immutable".
> 
> But the same is effectively true if security.evm is a digital
> signature and there's no symmetric key? For what we want to do (ensure
> that executables that are allowed to run with elevated privileges
> haven't been tampered with), that's completely ok.
> 
> >> 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?

A copy of the file could exist with a valid hmac on the system with
different security xattrs.  Without the inode/uuid, the xattrs could
be cut & pasted.

Ok, I agree this would be less of an issue for security.evm
signatures, since the signatures are not being generated on the
locally running system.

Mimi