Re: [RFC] EVM: Add support for portable signature format

[Mikhail Kurinnoi <viewizard@viewizard.com>]

? Thu, 26 Oct 2017 02:08:25 -0700
Matthew Garrett <mjg59@google.com> ?????:

> On Thu, Oct 26, 2017 at 2:03 AM, Mikhail Kurinnoi
> <viewizard@viewizard.com> wrote:
> > ? Thu, 26 Oct 2017 01:31:44 -0700
> > Matthew Garrett <mjg59@google.com> ?????:
> >  
> >> @@ -317,7 +319,7 @@ void ima_update_xattr(struct
> >> integrity_iint_cache *iint, struct file *file) int rc = 0;
> >>
> >>       /* do not collect and update hash for digital signatures */
> >> -     if (iint->flags & IMA_DIGSIG)
> >> +     if (iint->flags & IMA_DIGSIG || iint->flags &
> >> EVM_IMMUTABLE_DIGSIG) return;
> >>  
> >
> > Isn't this mean, we already changed files data, and we just don't
> > allow IMA xattr update? This file will not pass integrity
> > verification next time.  
> 
> That's fine - policy may not care. It's easier to sign all files and
> then leave enforcement up to the local policy than it is to determine
> in advance which files will need protection.
> 
> > I thought, the idea was prevent data changes, and in this way
> > prevent IMA xattr update.  
> 
> No, the goal is to be able to detect when files have been modified and
> (optionally) restrict access as a result. Otherwise the packaging
> system has to be able to identify all files that may be legitimately
> modified, which is something that may differ depending on the client.
> It's much easier to permit the data modification and have the local
> policy block reading or execution if it's actually a sensitive file.

Hmm...
http://www.spinics.net/lists/linux-integrity/msg00151.html

probably, we should decide first, what exactly immutable EVM mean.
It's hard to propose something or test patch if we still have
misunderstanding in concept of immutable EVM.


-- 
Best regards,
Mikhail Kurinnoi