Linux-Fsdevel Archive on
 help / color / Atom feed
From: Chuck Lever <>
	linux-fsdevel <>
Cc: Mimi Zohar <>,
	Michael Halcrow <>,
	"Theodore Y. Ts'o" <>,
	Matthew Garrett <>,
	Eric Biggers <>
Subject: Re: IMA on remote file systems
Date: Fri, 13 Sep 2019 10:50:41 -0400
Message-ID: <> (raw)
In-Reply-To: <>

Resending ...

> On Aug 28, 2019, at 1:36 PM, Chuck Lever <> 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: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2019-09-13 14:50 ` Chuck Lever [this message]
2019-09-15 21:42   ` Mimi Zohar

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Fsdevel Archive on

Archives are clonable:
	git clone --mirror linux-fsdevel/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-fsdevel linux-fsdevel/ \
	public-inbox-index linux-fsdevel

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox