Re: IMA on remote file systems

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	[thread overview]
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