On Mon, 2020-08-10 at 12:35 -0400, Mimi Zohar wrote: > On Mon, 2020-08-10 at 08:35 -0700, James Bottomley wrote: [...] > > > 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). > > I'm not opposed to doing that, but you're taking this discussion in a > totally different direction. The current discussion is about NFSv4 > supporting the existing IMA signatures, not only fs-verity > signatures. I'd like to understand how that is possible and for the > community to weigh in on whether it makes sense. Well, I see the NFS problem as being chunk at a time, right, which is merkle tree, or is there a different chunk at a time mechanism we want to use? IMA currently verifies signature on open/exec and then controls updates. Since for NFS we only control the client, we can't do that on an NFS server, so we really do need verification at read time ... unless we're threading IMA back to the NFS server? > > 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. > > > I was under the impression that IMA support for fs-verity signatures > would be limited to including the fs-verity signature in the > measurement list and verifying the fs-verity signature. As fs- > verity is limited to immutable files, this could be done on file > open. fs-verity would be responsible for enforcing the block/page > data integrity. From a local filesystem perspective, I think that > is all that is necessary. The fs-verity use case is a bit of a crippled one because it's immutable. I think NFS represents more the general case where you can't rely on immutability and have to verify at chunk read time. If we get chunk at a time working for NFS, it should work also for fs- verity and we wouldn't need to have two special paths. I think, even for NFS we would only really need to log the open, so same as you imagine for fs-verity. As long as the chunk read hashes match, we can be silent because everything is going OK, so we only need to determine what to do and log on mismatch (which isn't expected to happen for fs-verity). > In terms of remote file systems, the main issue is transporting and > storing the Merkle tree. As fs-verity is limited to immutable files, > this could still be done on file open. Right, I mentioned that in my options ... we need some "supply integrity" hook ... or possibly multiple hooks for a variety of possible methods. James
