lkml.org 
[lkml]   [2020]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE)
From
Date
On Mon, 2020-08-10 at 10:13 -0700, James Bottomley wrote:
> 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?

Yes. I still don't see how we can support the existing IMA signatures,
which is based on the file data hash, unless the "chunk at a time
mechanism" is not a tree, but linear.

Mimi

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

\
 
 \ /
  Last update: 2020-08-10 19:58    [W:0.097 / U:0.424 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site