Linux-Integrity Archive on lore.kernel.org
 help / color / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: linux-integrity@vger.kernel.org,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
	Michael Halcrow <mhalcrow@google.com>,
	"Theodore Y. Ts'o" <tytso@google.com>,
	Matthew Garrett <mjg59@google.com>,
	Eric Biggers <ebiggers@google.com>
Subject: Re: IMA on remote file systems
Date: Fri, 13 Sep 2019 10:50:41 -0400
Message-ID: <FA4C0F15-EE0A-4231-8415-A035C1CF3E32@oracle.com> (raw)
In-Reply-To: <C867A0BA-1ACF-4600-8179-3E15A098846C@oracle.com>

Resending ...

> On Aug 28, 2019, at 1:36 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
> 
> Last week I presented at the Linux Security Summit on a proposal
> for handling IMA metadata on NFS files. My proposal enables storage
> of per-file IMA metadata via the NFSv4 protocol. I have a prototype
> and an IETF nfsv4 Working Group document that specifies a small
> protocol extension.
> 
> After the presentation, Mimi Zohar pointed out that although the
> proposal extends protection from an NFS file server to time-of-
> measurement on an NFS client, there is still a protection gap between
> time-of-measurement and time-of-use on that client.
> 
> I would like to find a way to extend IMA protection all the way
> to time-of-use on NFS clients. The consensus is that a per-file
> Merkle tree would be the most desirable approach, as that is the
> same mechanism used for fs-verity protection.
> 
> For a few important reasons, it will be challenging to plumb
> support for durable Merkle trees into NFS, although that is an
> eventual goal.
> 
> My thought was to use an ephemeral Merkle tree for NFS (and
> possibly other remote filesystems, like FUSE, until these
> filesystems support durable per-file Merkle trees). A tree would
> be constructed when the client measures a file, but it would not
> saved to the filesystem. Instead of a hash of the file's contents,
> the tree's root signature is stored as the IMA metadata.
> 
> Once a Merkle tree is available, it can be used in exactly the
> same way that a durable Merkle tree would, to verify the integrity
> of individual pages as they are used, evicted, and then read back
> from the server.
> 
> If the client needs to evict part or all of an ephemeral tree, it
> can subsequently be reconstructed by measuring the file again and
> verifying its root signature against the stored IMA metadata.
> 
> So the only difference here is that the latency-to-first-byte
> benefit of a durable Merkle tree would be absent.
> 
> I'm interested in any thoughts or opinions about this approach.

--
Chuck Lever




  reply index

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-28 17:36 Chuck Lever
2019-09-13 14:50 ` Chuck Lever [this message]
2019-09-15 21:42   ` Mimi Zohar
2019-09-16 16:10     ` Theodore Y. Ts'o
2019-09-16 18:16       ` Chuck Lever
2019-09-16 13:16 ` Janne Karhunen
2019-09-16 14:47   ` Chuck Lever
2019-09-17  6:30     ` Janne Karhunen
2019-09-17 12:45       ` Theodore Y. Ts'o
2019-09-17 14:18         ` Mimi Zohar
2019-09-17 14:56         ` James Bottomley
2019-09-18  5:27           ` Janne Karhunen
2019-09-18 12:50             ` Theodore Y. Ts'o
2019-09-18 15:52             ` James Bottomley
2019-09-19  6:47               ` Janne Karhunen
2019-09-18 12:37           ` Theodore Y. Ts'o
2019-09-18 14:40             ` Mimi Zohar
2019-09-18 15:49             ` James Bottomley

Reply instructions:

You may reply publically 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=FA4C0F15-EE0A-4231-8415-A035C1CF3E32@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=ebiggers@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=mhalcrow@google.com \
    --cc=mjg59@google.com \
    --cc=tytso@google.com \
    --cc=zohar@linux.ibm.com \
    /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

Linux-Integrity Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-integrity/0 linux-integrity/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-integrity linux-integrity/ https://lore.kernel.org/linux-integrity \
		linux-integrity@vger.kernel.org linux-integrity@archiver.kernel.org
	public-inbox-index linux-integrity

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-integrity


AGPL code for this site: git clone https://public-inbox.org/ public-inbox