Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)
On Sun, 2020-08-09 at 13:16 -0400, Mimi Zohar wrote:
On Sat, 2020-08-08 at 13:47 -0400, Chuck Lever wrote:
> > On Aug 5, 2020, at 2:15 PM, Mimi Zohar <zohar(a)linux.ibm.com>
> > wrote:
<snip>
> > If block layer integrity was enough, there wouldn't have been a
> > need for fs-verity. Even fs-verity is limited to read only
> > filesystems, which makes validating file integrity so much
> > easier. From the beginning, we've said that fs-verity signatures
> > should be included in the measurement list. (I thought someone
> > signed on to add that support to IMA, but have not yet seen
> > anything.)
>
> Mimi, when you and I discussed this during LSS NA 2019, I didn't
> fully understand that you expected me to implement signed Merkle
> trees for all filesystems. At the time, it sounded to me like you
> wanted signed Merkle trees only for NFS files. Is that still the
> case?
I definitely do not expect you to support signed Merkle trees for all
filesystems. My interested is from an IMA perspective of measuring
and verifying the fs-verity Merkle tree root (and header info)
signature. This is independent of which filesystems support it.
>
> The first priority (for me, anyway) therefore is getting the
> ability to move IMA metadata between NFS clients and servers
> shoveled into the NFS protocol, but that's been blocked for various
> legal reasons.
Up to now, verifying remote filesystem file integrity has been out of
scope for IMA. With fs-verity file signatures I can at least grasp
how remote file integrity could possibly work. I don't understand
how remote file integrity with existing IMA formats could be
supported. You might want to consider writing a whitepaper, which
could later be used as the basis for a patch set cover letter.
I think, before this, we can help with the basics (and perhaps we
should sort them out before we start documenting what we'll do). The
first basic is that a merkle tree allows unit at a time verification.
First of all we should agree on the unit. Since we always fault a page
at a time, I think our merkle tree unit should be a page not a block.
Next, we should agree where the check gates for the per page accesses
should be ... definitely somewhere in readpage, I suspect and finally
we should agree how the merkle tree is presented at the gate. I think
there are three ways:
1. Ahead of time transfer: The merkle tree is transferred and verified
at some time before the accesses begin, so we already have a
verified copy and can compare against the lower leaf.
2. Async transfer: We provide an async mechanism to transfer the
necessary components, so when presented with a unit, we check the
log n components required to get to the root
3. The protocol actually provides the capability of 2 (like the SCSI
DIF/DIX), so to IMA all the pieces get presented instead of IMA
having to manage the tree
There are also a load of minor things like how we get the head hash,
which must be presented and verified ahead of time for each of the
above 3.
James