Re: IMA on remote file systems

[Mimi Zohar <zohar@linux.ibm.com>]

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@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.

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