All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	Roberto Sassu <roberto.sassu@huawei.com>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	"linux-security-module@vger.kernel.org" 
	<linux-security-module@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Silviu Vlasceanu <Silviu.Vlasceanu@huawei.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [RESEND][PATCH] ima: Set and clear FMODE_CAN_READ in ima_calc_file_hash()
Date: Tue, 17 Nov 2020 18:23:41 -0500	[thread overview]
Message-ID: <5d8fa26d376999f703aac9103166a572fc0df437.camel@linux.ibm.com> (raw)
In-Reply-To: <CAHk-=wih-ibNUxeiKpuKrw3Rd2=QEAZ8zgRWt_CORAjbZykRWQ@mail.gmail.com>

On Tue, 2020-11-17 at 10:23 -0800, Linus Torvalds wrote:
> On Mon, Nov 16, 2020 at 10:35 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > We need to differentiate between signed files, which by definition are
> > immutable, and those that are mutable.  Appending to a mutable file,
> > for example, would result in the file hash not being updated.
> > Subsequent reads would fail.
> 
> Why would that require any reading of the file at all AT WRITE TIME?

On the (last) file close, the file hash is re-calculated and written
out as security.ima.  The EVM hmac is re-calculated and written out as
security.evm.

> 
> Don't do it. Really.

I really wish it wasn't needed.

> 
> When opening the file write-only, you just invalidate the hash. It
> doesn't matter anyway - you're only writing.
> 
> Later on, when reading, only at that point does the hash matter, and
> then you can do the verification.
> 
> Although honestly, I don't even see the point. You know the hash won't
> match, if you wrote to the file.

On the local system, as Roberto mentioned, before updating a file, the
existing file's data and metadata (EVM) should be verified to protect
from an offline attack.

The above scenario assumes calculating the file hash is only being used
for verifying the integrity of the file (security.ima), but there are
other reasons for calculating the file hash.  For example depending on
the IMA measurement policy, just accessing a file could require
including the file hash in the measurement list.  True that measurement
will only be valid at the time of measurement, but it provides a base
value.

Mimi


  parent reply	other threads:[~2020-11-17 23:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-13  8:01 [RESEND][PATCH] ima: Set and clear FMODE_CAN_READ in ima_calc_file_hash() Roberto Sassu
2020-11-13 15:53 ` Mimi Zohar
2020-11-14 11:10 ` Christoph Hellwig
2020-11-16  8:52   ` Roberto Sassu
2020-11-16 16:22     ` Christoph Hellwig
2020-11-16 16:46       ` Mimi Zohar
2020-11-16 17:37         ` Linus Torvalds
2020-11-16 17:41           ` Christoph Hellwig
2020-11-16 18:09             ` Linus Torvalds
2020-11-16 18:35               ` Mimi Zohar
2020-11-17 18:23                 ` Linus Torvalds
2020-11-17 18:54                   ` Theodore Y. Ts'o
2020-11-17 23:23                   ` Mimi Zohar [this message]
2020-11-17 23:29                     ` Linus Torvalds
2020-11-17 23:36                       ` Linus Torvalds
2020-11-18 18:28                         ` Mimi Zohar
2020-11-20 12:52                         ` Roberto Sassu
2020-11-16 18:21             ` Mimi Zohar
2020-11-16 18:08           ` Al Viro
2020-11-16 18:49             ` Mimi Zohar
2020-11-17 12:29             ` Roberto Sassu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5d8fa26d376999f703aac9103166a572fc0df437.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=Silviu.Vlasceanu@huawei.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=roberto.sassu@huawei.com \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.