Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
Message-ID: <760DF127-CA5F-4E86-9703-596E95CEF12F@oracle.com>
Date:   Wed, 26 Aug 2020 10:13:43 -0700 (PDT)
From:   Chuck Lever <chuck.lever@oracle.com>
To:     Eric Biggers <ebiggers@kernel.org>
Cc:     linux-fscrypt@vger.kernel.org, linux-integrity@vger.kernel.org,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: IMA metadata format to support fs-verity
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

Hi Eric-

I'm trying to construct a viable IMA metadata format (ie, what
goes into security.ima) to support Merkle trees.

Rather than storing an entire Merkle tree per file, Mimi would
like to have a metadata format that can store the root hash of
a Merkle tree. Instead of reading the whole tree, an NFS client
(for example) would generate the parts of the file's fs-verity
Merkle tree on-demand. The tree itself would not be exposed or
transported by the NFS protocol.

Following up with the recent thread on linux-integrity, starting
here:

  =
https://lore.kernel.org/linux-integrity/1597079586.3966.34.camel@HansenPar=
tnership.com/t/#u

I think the following will be needed.

1. The parameters for (re)constructing the Merkle tree:
- The name of the digest algorithm
- The unit size represented by each leaf in the tree
- The depth of the finished tree
- The size of the file
- Perhaps a salt value
- Perhaps the file's mtime at the time the hash was computed
- The root hash

2. A fingerprint of the signer:
- The name of the digest algorithm
- The digest of the signer's certificate

3. The signature
- The name of the signature algorithm
- The signature, computed over 1.

Does this seem right to you?

There has been some controversy about whether to allow the
metadata to be unsigned. It can't ever be unsigned for NFS files,
but some feel that on a physically secure local-only set up,
signatures could be unnecessary overhead. I'm not convinced, and
believe the metadata should always be signed: that's the only
way to guarantee end-to-end integrity, which includes protection
of the content's provenance, no matter how it is stored.

--
Chuck Lever