On Fri, 2019-09-13 at 10:50 -0400, Chuck Lever wrote: > Resending ... > > > On Aug 28, 2019, at 1:36 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> 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. I like the idea, but there are a couple of things that need to happen first. Both fs-verity and IMA appended signatures need to be upstreamed. The IMA appended signature support simplifies ima_appraise_measurement(), paving the way for adding IMA support for other types of signature verification. How IMA will support fs-verity signatures still needs to be defined. That discussion will hopefully include NFS support. Mimi