Re: RFC: Make it practical to ship EVM signatures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



В Mon, 09 Oct 2017 17:10:49 -0400
Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> пишет:

> On Mon, 2017-10-09 at 23:23 +0300, Mikhail Kurinnoi wrote:
> > В Mon, 09 Oct 2017 14:40:41 -0400
> > Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> пишет:
> >   
> > > On Mon, 2017-10-09 at 11:18 -0700, Matthew Garrett wrote:  
> > > > On Mon, Oct 9, 2017 at 11:15 AM, Mimi Zohar
> > > > <zohar@xxxxxxxxxxxxxxxxxx> 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?


-- 
Best regards,
Mikhail Kurinnoi




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux