Re: RFC: Make it practical to ship EVM signatures

From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Mikhail Kurinnoi <viewizard@viewizard.com>
Cc: Matthew Garrett <mjg59@google.com>,
	linux-integrity@vger.kernel.org,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
Subject: Re: RFC: Make it practical to ship EVM signatures
Date: Mon, 09 Oct 2017 17:40:53 -0400	[thread overview]
Message-ID: <1507585253.3748.57.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20171010003326.6409ae23@totoro>

[Cc'ing Dmitry Kasatkin]

On Tue, 2017-10-10 at 00:33 +0300, Mikhail Kurinnoi wrote:
> ? Mon, 09 Oct 2017 17:10:49 -0400
> Mimi Zohar <zohar@linux.vnet.ibm.com> ?????:
> 
> > On Mon, 2017-10-09 at 23:23 +0300, Mikhail Kurinnoi wrote:
> > > ? Mon, 09 Oct 2017 14:40:41 -0400
> > > Mimi Zohar <zohar@linux.vnet.ibm.com> ?????:
> > >   
> > > > On Mon, 2017-10-09 at 11:18 -0700, Matthew Garrett wrote:  
> > > > > On Mon, Oct 9, 2017 at 11:15 AM, Mimi Zohar
> > > > > <zohar@linux.vnet.ibm.com> wrote:    
> > > > > > On Mon, 2017-10-09 at 10:59 -0700, Matthew Garrett wrote:    
> > > > > >> 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!    
> > > > > 
> > > > > Excellent. This means defining a new signature type - the two
> > > > > options seem to be Mikhail's portable format, or the approach I
> > > > > took of having the signature define which metadata is included.
> > > > > Do you have a preference?    
> > > > 
> > > > We now understand that as long as the EVM signature includes
> > > > security.ima, it is safe not to include the i_ino/uuid.  This new
> > > > format can be written to disk.  
> > > 
> > > But, isn't this mean we could have this scenario of offline
> > > manipulations:
> > > 1) store old file with xattrs;
> > > 2) wait;
> > > 3) replace new file with fixed exploits on old one.
> > > 
> > > Since we don't have directory tree protection yet and we don't use
> > > i_ino, someone could reuse old files more easy during offline
> > > manipulations. Right?  
> > 
> > As long as the new EVM signature format requires the existence of a
> > security.ima xattr, I don't see how.  The new EVM signature format
> > would not be replaced with an HMAC.
> 
> 
> I understood the idea.
> 
> Looks like portable EVM format support proposed by Matthew, could be
> easy realized. Probably, will be good idea add only this one, test it,
> and later add immutable EVM format and portable EVM format that
> converted into HMAC (that I proposed in patch set)?
> 
> If no one ask for portable EVM format that converted into HMAC, do we
> really need push all in one bunch?

It looks like Dmitry already defined a new "immutable" EVM  signature
format in ima-evm-utils and posted the corresponding patch to linux-
ima-devel a long time ago.

The new "immutable" EVM signature doesn't include the i_ino or
generation.

Mimi