Re: RFC: Make it practical to ship EVM signatures

From: Mikhail Kurinnoi <viewizard@viewizard.com>
To: Mimi Zohar <zohar@linux.vnet.ibm.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: Tue, 10 Oct 2017 02:10:52 +0300	[thread overview]
Message-ID: <20171010021052.47d42db6@totoro> (raw)
In-Reply-To: <1507585253.3748.57.camel@linux.vnet.ibm.com>

? Mon, 09 Oct 2017 17:40:53 -0400
Mimi Zohar <zohar@linux.vnet.ibm.com> ?????:

> [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.

Yes. Btw, Dmitry's patch is the base of proposed by me "portable"
version support patch:
https://sourceforge.net/p/linux-ima/mailman/message/35587348/
since for portable format we use same idea - EVM signature format
without i_ino/generation/uuid.
Plus, that was the reason for keep for "portable" format
signature version number "3", since Dmitry already did all changes in
ima-evm-utils, portable format could be tested.

In the same time, I proposed "immutable" EVM signature, that
identically to current EVM digsig (with i_ino,...), but can't be
changed into HMAC. This patch don't related to Dmitry's "immutable" EVM
signature format support:
https://sourceforge.net/p/linux-ima/mailman/message/35601151/
I didn't really work on "immutable" EVM signature, only "portable"
version support needs was taken into account.

For now, we don't have ready for upstream "immutable" EVM signature
format support patch. Both, Dmitry's and my, patches need more work
in order to prevent file's data changes (in case of IMA hash) and
metadata changes for files signed by "immutable" EVM xattr (same idea
as we already have for IMA digsig, that prevent file's data change).

-- 
Best regards,
Mikhail Kurinnoi