On Sat, 2020-08-08 at 13:47 -0400, Chuck Lever wrote: > > On Aug 5, 2020, at 2:15 PM, Mimi Zohar <zohar@xxxxxxxxxxxxx> 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. Mimi > > IMO we need agreement from everyone (integrity developers, FS > implementers, and Linux distributors) that a signed Merkle tree IMA > metadata format, stored in either an xattr or appended to an executable > file, will be the way forward for IMA in all filesystems.
