В Thu, 26 Oct 2017 02:08:25 -0700 Matthew Garrett <mjg59@xxxxxxxxxx> пишет: > On Thu, Oct 26, 2017 at 2:03 AM, Mikhail Kurinnoi > <viewizard@xxxxxxxxxxxxx> wrote: > > В Thu, 26 Oct 2017 01:31:44 -0700 > > Matthew Garrett <mjg59@xxxxxxxxxx> пишет: > > > >> @@ -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
