From: Mimi Zohar <zohar@linux.ibm.com>
To: Matthew Garrett <mjg59@google.com>, linux-integrity@vger.kernel.org
Cc: dmitry.kasatkin@gmail.com, miklos@szeredi.hu,
linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk
Subject: Re: Allow FUSE filesystems to provide out-of-band hashes to IMA
Date: Fri, 05 Oct 2018 06:49:26 -0400 [thread overview]
Message-ID: <1538736566.3702.436.camel@linux.ibm.com> (raw)
In-Reply-To: <20181004203007.217320-1-mjg59@google.com>
Hi Matthew,
On Thu, 2018-10-04 at 13:30 -0700, Matthew Garrett wrote:
> As of d77ccdc644a59b412d8e101576134c90a0aa6797, IMA will trigger a
> rehash of any file on a FUSE filesystem for every measurement. This has
> a significant impact on performance. Individual FUSE filesystems may
> have the ability to identify whether a file needs to be rehashed, and
> some may even have the ability to obtain the file hash out of band
> without needing the kernel to do it. Longer term, this may also be
> usable for other scenarios where a filesystem can provide a trustworthy
> hash (eg, fs-verity on ext4 could provide a hash and then later abort
> any read()s that discover that the file doesn't match the measurement).
Really, a security vs. performance argument?! I don't need to tell
you of all people, that one of the basic tenents of trusted boot is
calculating the actual file hash before use. Limiting the file hash
re-calculation is one thing, but relying on some out of band method of
obtaining the file hash without the kernel ever calculating it is
totally different. The only exception will be for fs-verity, which
will return not the file hash, but the file's Merkle tree root hash.
If you want to introduce support for identifying whether a FUSE file,
on a trusted mount, needs to be rehashed, that's fine. It should not
be the default behavior.
Mimi
next prev parent reply other threads:[~2018-10-05 17:49 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-04 20:30 Allow FUSE filesystems to provide out-of-band hashes to IMA Matthew Garrett
2018-10-04 20:30 ` [PATCH 1/3] VFS: Add a call to obtain a file's hash Matthew Garrett
2018-10-11 15:22 ` Mimi Zohar
2018-10-11 18:21 ` Matthew Garrett
2018-10-11 18:24 ` Matthew Garrett
2018-10-11 18:37 ` Mimi Zohar
2018-10-11 18:43 ` Matthew Garrett
2018-10-04 20:30 ` [PATCH 2/3] IMA: Make use of filesystem-provided hashes Matthew Garrett
2018-10-11 15:23 ` Mimi Zohar
2018-10-11 20:30 ` Matthew Garrett
2018-10-11 23:03 ` Mimi Zohar
2018-10-12 18:31 ` Matthew Garrett
2018-10-15 1:38 ` Mimi Zohar
2018-10-15 18:46 ` Matthew Garrett
2018-10-16 13:16 ` Mimi Zohar
2018-10-04 20:30 ` [PATCH 3/3] FUSE: Allow filesystems to provide gethash methods Matthew Garrett
2018-10-05 10:49 ` Mimi Zohar [this message]
2018-10-05 17:26 ` Allow FUSE filesystems to provide out-of-band hashes to IMA Matthew Garrett
2018-10-05 18:18 ` Mimi Zohar
2018-10-05 19:25 ` Matthew Garrett
2018-10-08 11:25 ` Mimi Zohar
2018-10-08 20:19 ` Matthew Garrett
2018-10-08 22:40 ` Mimi Zohar
2018-10-09 17:21 ` Matthew Garrett
2018-10-09 18:04 ` Mimi Zohar
2018-10-09 19:29 ` Matthew Garrett
2018-10-09 20:52 ` Mimi Zohar
2018-10-09 21:32 ` Matthew Garrett
2018-10-10 11:09 ` Mimi Zohar
2018-10-10 16:19 ` Matthew Garrett
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=1538736566.3702.436.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mjg59@google.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).